Hurd plus rumpdisk with low total system memory
I've been trying to achieve a minimal system installation on a very old
Netbook with limited resources. Total system memory is 1Gb RAM but the
issue reported here also occurs on a 1Gb Qemu virtual machine. This is
all 32 bit which I've specifically been using for stress testing to
isolate from any 64 bit port instability.
Under such a modest system, the HIGHMEM memory segment is small (151M in
my case), most of the memory appears in the DIRECTMAP segment. After
rumpdisk task is initialised, HIGHMEM is completely exhausted (possible
as rumpdisk is vm_privileged) and all (or almost all) of the pages are
wired. Pageout is triggered but no pages can be moved or evicted from
the segment as none of them are pageable and consequently page
allocation to any non vm-privileged task is suspended.
I made a gross hack to vm_page_convert to use DIRECTMAP rather than
HIGHMEM for page allocation specifically for the rumpdisk task solely to
see if the system then booted which it did. I had a few ideas for
software changes to fix this properly and although some of them worked
to a degree, they also introduced performance difficulties during later
pageout tests. If this configuration was to be supported, I think more
substantial work might be needed to fix the problem.
I notice that the 64 bit port has different memory segments. With 1Gb
RAM Qemu shows a 15M DMA segment and the rest in one DIRECTMAP segment.
I think the segmentation on 32 bit relates to kernel memory access
restrictions for direct mapping which presumably does not apply on 64
bit. Anyway, that's an aside really, what I really wanted to know is
what importance should be attached to this issue, given that it's not
likely relevant to many with modern hardware. Is it worth me putting in
any effort to address it at all or should I simply abandon that old,
small machine?
Regards,
Mike.
Reply to: