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.

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