From 8cee055ec4fac00e59f19620ab06e2b30dccee3c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@gnu.org>
Date: Wed, 11 Jul 2012 22:39:59 +0200
Subject: IRC.

---
 microkernel/mach/gnumach/memory_management.mdwn | 35 ++++++++++++++++++-------
 1 file changed, 26 insertions(+), 9 deletions(-)

(limited to 'microkernel/mach/gnumach/memory_management.mdwn')

diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index ca2f42c4..c630af05 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -8,9 +8,12 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled [[GNU Free Documentation
 License|/fdl]]."]]"""]]
 
-[[!tag open_issue_documentation]]
+[[!tag open_issue_documentation open_issue_gnumach]]
 
-IRC, freenode, #hurd, 2011-02-15
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-02-15
 
     <braunr> etenil: originally, mach had its own virtual space (the kernel
       space)
@@ -37,14 +40,15 @@ IRC, freenode, #hurd, 2011-02-15
       lage - pages without resetting the mmu often thanks to global pages, but
       that didn't exist at the time)
 
-IRC, freenode, #hurd, 2011-02-15
+
+# IRC, freenode, #hurd, 2011-02-15
 
     <antrik> however, the kernel won't work in 64 bit mode without some changes
       to physical memory management
     <braunr> and mmu management
     <braunr> (but maybe that's what you meant by physical memory)
 
-IRC, freenode, #hurd, 2011-02-16
+## IRC, freenode, #hurd, 2011-02-16
 
     <braunr> antrik: youpi added it for xen, yes
     <braunr> antrik: but you're right, since mach uses a direct mapped kernel
@@ -52,9 +56,7 @@ IRC, freenode, #hurd, 2011-02-16
     <braunr> which isn't required if the kernel space is really virtual
 
 
----
-
-IRC, freenode, #hurd, 2011-06-09
+# IRC, freenode, #hurd, 2011-06-09
 
     <braunr> btw, how can gnumach use 1 GiB of RAM ? did you lower the
       user/kernel boundary address ?
@@ -82,7 +84,7 @@ IRC, freenode, #hurd, 2011-06-09
       RAM to fill the kernel space with struct page entries
 
 
-IRC, freenode, #hurd, 2011-11-12
+# IRC, freenode, #hurd, 2011-11-12
 
     <youpi> well, the Hurd doesn't "artificially" limits itself to 1.5GiB
       memory
@@ -102,3 +104,18 @@ IRC, freenode, #hurd, 2011-11-12
     <youpi> kernel space is what determines how much physical memory you can
       address
     <youpi> unless using the linux-said-awful "bigmem" support
+
+
+# IRC, freenode, #hurd, 2012-07-05
+
+    <braunr> hm i got an address space exhaustion while building eglibc :/
+    <braunr> we really need the 3/1 split back with a 64-bits kernel
+    <pinotree> 3/1?
+    <braunr> 3 GiB userspace, 1 GiB kernel
+    <pinotree> ah
+    <braunr> the debian gnumach package is patched to use a 2/2 split
+    <braunr> and 2 GiB is really small for some needs
+    <braunr> on the bright side, the machine didn't crash
+    <braunr> there is issue with watch ./slabinfo which turned in a infinite
+      loop, but it didn't affect the stability of the system
+    <braunr> actually with a 64-bits kernel, we could use a 4/x split
-- 
cgit v1.2.3