Re: Small highmem segment with 32bit gnumach
Hello,
As mentioned by Richard, you'll reach much more targetted audience if
you mail bug-hurd.
João Pedro Malhado, le jeu. 25 sept. 2025 23:12:34 +0100, a ecrit:
> As Mike has outline recently, if a system has 1 GB of RAM one will end up with a
> 141MB highmem segment. This prevents booting the hurd with rumpdisk as he
> described, but the problems run deeper than that. Even booting the system using
> the ide drivers in gnumach, the system is sluggish, takes a long time to perform
> certain tasks, and can become unresponsive. The system becomes unresponsive
> for example while upgrading the hurd package, which while setting up the
> translators launches rumpdisk (I think because of the detected USB ports). I
> don't think this is related to rumpdisk per se, but how gnumach is managing
> memory.
> In comparison, a laptop with 512MB of RAM runs much more smoothly than one with
> 1024MB!
> Is this because only the highmem segment with 141MB is being used for the
> user space?
No, vm_page_alloc_pa also falls back to directmap etc.
> It was mentioned that it is not worth investing time in fixing the 32bit kernel,
In general, yes. But the slugginess you mention could possibly also
happen on 64bit depending on the memory layout etc. It'd be useful to
determine where exactly it's spending time: is it trying to release
memory from the highmem segment just because it doesn't realize that
it's lost cause since it's all wired down anyway? Possibly the
statistics about "being full" need to be fixed to take into account the
wired memory which won't move anyway.
> but I wonder if there is some sort of workaround. Is it possible to limit the
> amount of memory that is "shown to" gnumach such that it maps only the directmap
> segment and ignores the extra 141MB?
> Is there a gnumach boot option that would work like mem=XX in linux?
I'm not aware of any, but it should be easy to implemented, by changing
the value given to biosmem_load_segment inside biosmem_setup.
> Reading some old documentation I saw the uppemem option in grub, but
> this did not change anything (or I did not use it correctly).
IT's not uppemem, but uppermem, which grub2 does not support any more
apparently.
> Or would anyone be able to suggest a patch for gnumach to just ignore the
> highmem segment which I could apply?
You can just change the hardcoded value in biosmem_setup for a start.
Samuel
Reply to: