IRC channel logs
2025-03-20.log
back to list of logs
<Pellescours>I tried to build a 64bit image (with cross-hurd from flavioc), and my VM do not have network. Does someone have an idea with networking in 64bit mode? <Pellescours>that what I though, but I need to understand why my VM is not able to reach internet <Pellescours>i cant do anything right now, I will continue investigation tonight <camm>Linux can break total mem down into ram and swap via sysinfo, but on hurd apparently only total mem via sysconf(_SC_PHYS_PAGES)? <youpi>camm: swap information is available through the default_pager_info RPC <youpi>see e.g. how hurd/utils/vmstat.c gets it <camm>Using the new image under kvm, hurd-amd64/GCL works when restricting memory to 1Gb, but when unrestricted to default 2Gb, kernel reports ~ 'vm cannot recycle any page' <youpi>camm: how much memory did you give to your vm ? <camm>kvm -M q35 -m 2G -drive file=debian-hurd-amd64-20250316.img,cache=writeback -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 <camm>I can let GCL see all the ambient memory, or restrict it with an evironment variable <camm>The failure was in unrestricted <youpi>rumpdisk eats quite a lot of memory, you can't hope gcl to use 2G if the vm itself has only 2G <camm>The algorithm does not hope to use all the memory, just use it as an upper bound for mmap <camm>Actual use is typically 1/2, with GC reclaiming space as needed. <camm>I did not get any system call failure, nor segfault, just a lockup with the kernel reporting that message in the QEMU window <youpi>so the os doesn't have any way <youpi>at beast we'd have the overcommit feature integrated <youpi>there's a patch on the list, some issues were seen and need to be confirmed/invalidated <youpi>then you'd see mmap fail indeed <youpi>but the principle would be the same: you can't hope to be able to use as much memory as the vm has <camm>If I understand correctly, adding a swapfiile won't help with this test. <youpi>it would, the os would be able to push your anonymous data to swap <camm>But the total memory seen would also increase. <camm>But as a user, if again I understand you correctly, I should expect to see the condition via a failed call to mmap, right? <camm>I reported before some rather extreme overcommit behavior, if I recall correctly, mmap succeeds with some hopelessly large value without ENOMEM <camm>I limit by hand according to physical memory available as an upper bound <camm>I will retry with a swapfile <youpi>don't use the physical memory, but half of it <youpi>that's what linux uses as arbitrary limit for mmaps (without swap) <youpi>don't enable a swapfile on x86_64, you'll get hangs <youpi>rumpdisk does get some pages swapped out and then we can't swap them in again <youpi>again, we do want to have an overcommit limitation at some point <youpi>you can do it yourself by limiting yourself to have the physical memory + swap (as linux does) <youpi>(and which is what we'll do=) <camm>Great, thanks, will test this! <camm>MemTotal: in /proc/meminfo changes from run to run? <youpi>it can change depending on some kernel allocations, probably <camm>seems a phyical constant on Linux, mod swapon... <camm>doesn't seem to change much <camm>how can MemFree in /proc/meminfo be less than SwapFree? <youpi>MemFree doesn't include swaf <camm>but memtotal includes swaptotal? <camm>well that was embarrassing -- thanks so much! <camm>is this mmap overcommit issue any different on hurd-i386? <camm>And also, GCL has thhe ability to move the cstack to a convenient location on 32bit systems, but this uses MAP_GROWSDOWN which is lacking. <camm>Yes clone/sigaltstack must be able to relocate the stack, any idea how it is done? <youpi>there is no difference on hurd-i386, it's "just" that you get naturally limited to the 3G addressing space <youpi>do you really need GROWSDOWN? <youpi>I mean the provided stack does not grow <youpi>so you can just mmap another memory and use it <youpi>it won't be worse than what you already have <camm>I did not know that -- OK, this can be done, apparently also the case on sh4 btw. <camm>right now we use a linker script to raise text above the stack, slightly less optimal <Pellescours>I was able to get the network on my 64bit machine to work <Pellescours>probably the lucas yesteday patch would have worked too <camm>I tried apt-get upgrade in the new hurd-amd64 image thinking it would be close enough, but the but the behavior is radically different. maps being placed at around 0x20000000 now. I am hoping this is an artifact and the lesson is not to upgrade the image....