summaryrefslogtreecommitdiff
path: root/microkernel/mach/gnumach/memory_management.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'microkernel/mach/gnumach/memory_management.mdwn')
-rw-r--r--microkernel/mach/gnumach/memory_management.mdwn44
1 files changed, 44 insertions, 0 deletions
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index 3e158b7c..a1d9a99d 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -133,3 +133,47 @@ License|/fdl]]."]]"""]]
<braunr> using sysenter/sysexit makes it even faster
[[open_issues/system_call_mechanism]].
+
+
+# IRC, freenode, #hurd, 2012-12-12
+
+ <braunr> youpi: is the 2g split patch really needed ?
+ <braunr> or rather, is it really a good thing for most people ?
+ <braunr> instead of the common 3g/1g
+ <braunr> it reduces tasks' address space but allows the kernel to reference
+ more physical memory
+ <braunr> the thing is, because of the current page cache implementation,
+ most of the time, this physical memory remains unused, or very rarely
+ <youpi> ?
+ <braunr> on the other hand, a larger address space for tasks allows running
+ more threads (more space for tasks) and not failing while linking webkit
+ .. :)
+ <youpi> it's needed for quite a few compilations, yes
+ <braunr> if you refer to the link stage, with a decent amount of swap, it
+ goes without trouble
+ <youpi> well, if your kernel doesn't have 2GiB physical addressing
+ capacity, userspace won't have >2GiB memory capacity either
+ <youpi> does it now?
+ <youpi> it didn't use to
+ <youpi> and it was crawling like hell for some builds
+ <youpi> (until simply hanging)
+ <braunr> i never have a problem e.g. runing the big malloc glibc test
+ <braunr> (bug22 or something like that)
+ <youpi> that doesn't involve objects from the fs, does it?
+ <braunr> no
+ <braunr> as long as it's anonymous memory, it's ok
+ <braunr> the default pager looks safe, i'm pretty sure our lockups are
+ because of something in ext2fs
+ <youpi> braunr: well, an alternative would be to build two kernels, one 2/2
+ and one 3/1
+ <braunr> not really worth it
+ <braunr> i was just wondering
+ <braunr> i usually prefer a 3/1 on darnassus, but i don't build as often as
+ a buildd :x
+ <youpi> or we can go with 2.5/1.5
+ <youpi> I can do that on bach & mozart for instance
+ <youpi> (they have their own kernel anyway)
+ <braunr> youpi: if you think it's worth the effort
+ <braunr> again, i was just wondering out loud
+ <youpi> braunr: well, bach & mozart don't have > 1.2GiB mem anyway
+ <youpi> so it doesn't pose problem