diff options
Diffstat (limited to 'microkernel/mach/gnumach/memory_management.mdwn')
| -rw-r--r-- | microkernel/mach/gnumach/memory_management.mdwn | 35 |
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 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 |