Wiki Edits: adding Richard's comment about mach's memory management issues

[Joshua Branson]

Richard mentioned this issue a few days ago regarding tmpfs changes. I
am adding it to the wiki under open issues/gnumach memory management.

I also removed the link to the FOSS bounty. It looks like that bounty
has been paid already? Perhaps we should keep the link open in case
someone wants to contribute more money to it?

Also, I discovered that we have 3 pages on gnumach memory management.

https://www.gnu.org/software/hurd/microkernel/mach/gnumach/memory_management.html

https://www.gnu.org/software/hurd/open_issues/gnumach_memory_management.html

https://www.gnu.org/software/hurd/open_issues/gnumach_memory_management_2.html

The first two are probably outdated, and I could try to update them in a bit.
And I should probably combine the two open issues memory management pages...

[Samuel Thibault]

Hello,

-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.

Samuel

[Joshua Branson]

Post by Samuel Thibault
Hello,

-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.

Post by Samuel Thibault
Samuel