path: root/microkernel/mach/gnumach/memory_management.mdwn
diff options
authorThomas Schwinge <>2012-07-11 22:39:59 +0200
committerThomas Schwinge <>2012-07-11 22:39:59 +0200
commit8cee055ec4fac00e59f19620ab06e2b30dccee3c (patch)
tree6cd7ca1b8ce7eba1820fdbd31ee5755ed33dabe2 /microkernel/mach/gnumach/memory_management.mdwn
parentb75e038615d51cb62c200e336e59202519db8cae (diff)
Diffstat (limited to 'microkernel/mach/gnumach/memory_management.mdwn')
1 files changed, 26 insertions, 9 deletions
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
-[[!tag open_issue_documentation]]
+[[!tag open_issue_documentation open_issue_gnumach]]
-IRC, freenode, #hurd, 2011-02-15
+# IRC, freenode, #hurd, 2011-02-15
<braunr> etenil: originally, mach had its own virtual space (the kernel
@@ -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
@@ -102,3 +104,18 @@ IRC, freenode, #hurd, 2011-11-12
<youpi> kernel space is what determines how much physical memory you can
<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