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...
>From e31ab0fc0c60cc6328fb8a7affb271eb7cb33ea1 Mon Sep 17 00:00:00 2001 From: Joshua Branson <jbra...@fastmail.com> Date: Wed, 7 Nov 2018 10:32:38 -0500 Subject: [PATCH] I am adding Richard's comment about mach's memory management issue to the open issues gnumach memory management page. I also added a link to the 64-bit port on the 830MB RAM limit page. --- faq/ram_limit.mdwn | 12 ++++++++---- open_issues/64-bit_port.mdwn | 2 +- open_issues/gnumach_memory_management.mdwn | 16 ++++++++++++++-- 3 files changed, 23 insertions(+), 7 deletions(-) diff --git a/faq/ram_limit.mdwn b/faq/ram_limit.mdwn index 5017925c..8e13f321 100644 --- a/faq/ram_limit.mdwn +++ b/faq/ram_limit.mdwn @@ -13,10 +13,14 @@ License|/fdl]]."]]"""]] [[!meta title="830 MiB RAM Limit"]] -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. + +There is a [[64-bit port|open_issues/64-bit_port]] in progress. If you have an older version, or still experience problems with `vmstat` (see above) reported much less memory than you have, the best is to limit the memory diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index 8658f1b7..656dd450 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.mdwn @@ -19,7 +19,7 @@ What is left for initial support (32-on-64) is * adding 64bit boot support from grub * implement 32/64 RPC compatibility for RPCs served by kernel. -See http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00000.html +See [[http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00000.html]] For pure 64bit support, we need to diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 8eb0cf8a..911c2b51 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -11,8 +11,6 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -There is a [[!FF_project 266]][[!tag bounty]] on this task. - [[!toc]] @@ -2389,3 +2387,17 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. <braunr> well, there is also a locking error in the slab allocator, although not a problem for a non preemptible kernel like gnumach <braunr> non preemptible / uniprocessor + +## IRC freenode, #hurd, 2016-12-29 + + <braunr> i've identified a fundamental flaw with the default pager + <braunr> and actually, with mach in general i suppose + <braunr> i assumed that it was necessary to trust the server only + <braunr> that a server didn't need to trust its client + <braunr> but mach messages carry memory that is potentially mapped from unprivileged pagers + <braunr> which means faulting on that memory effectively makes the faulting process a client to the unprivileged pager + <braunr> and that's something that can happen to the default pager during heavy memory pressure + <braunr> in which case it deadlocks on itself because the copyout hangs on a fault, waiting for the unprivileged pager to provide the data + <braunr> (which it can't because of heavy memory pressure and because it's unprivileged, it's blocked, waiting until allocations resume) + <braunr> the pageout daemon will keep paging out to the default pager in the hope those pages get freed + <braunr> but sending to the default pager is now impossible because its map is locked on the never-ending fault -- 2.19.1
Thanks, Joshua
