[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Wiki Edits: adding Richard's comment about mach's memory management
From: |
Joshua Branson |
Subject: |
Re: Wiki Edits: adding Richard's comment about mach's memory management issues |
Date: |
Fri, 09 Nov 2018 08:00:20 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Samuel Thibault <samuel.thibault@gnu.org> writes:
> Hello,
>
> Joshua Branson, le mer. 07 nov. 2018 12:00:48 -0500, a ecrit:
>> -Just like any 32-bit OS without bad tricks, GNU Mach can not cope well with
>> lots
>> -of memory. Latest versions of the Debian `gnumach` package will limit
>> themselves
>> -to around 1.7 GiB of memory. If you want more, you can twiddle the
>> `VM_MAX_ADDRESS`
>> -limit between kernelland and userland in
>> `i386/include/mach/i386/vm_param.h`.
>> +The 830MB RAM limit has been removed, but just like any 32-bit OS without
>> bad tricks,
>> +GNU Mach can not cope well with lots of memory. Latest versions of the
>> Debian `gnumach`
>> +package will limit themselves to 3 GiB of memory. If you want more, you can
>> twiddle
>> +the `VM_MAX_ADDRESS` limit between kernelland and userland in
>> +`i386/include/mach/i386/vm_param.h`, but glibc and the hurd servers will
>> not cope
>> +well with less than 1 GB.
>
> Mmm, this is outdated. Richard implemented the highmem mapping support
> needed to manage more than 2-3GiB of memory, so we don't have that
> limitation any more. It's however still useful to mention that managing
> a lot of memory with 32bit systems is a bit costly and the 64bit port
> would help on this.
Ok. I'll see if I can't find that commit message somewhere to find out
more about Richard's highmem mapping support, and perhaps I'll mention
your comment "It's however still useful to mention that managing
a lot of memory with 32bit systems is a bit costly and the 64bit port
would help on this" on that FAQ page.
>
> Samuel