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.