open_issues/performance/io_system/clustered_page_faults: New. And some more IRC discussions.

3 files changed, 31 insertions, 3 deletions

diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn
index d9b6c2c8..05a6cc56 100644
--- a/microkernel/mach/external_pager_mechanism.mdwn
+++ b/microkernel/mach/external_pager_mechanism.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2007, 2008, 2010 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2002, 2007, 2008, 2010, 2011 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
@@ -181,3 +181,15 @@ fashion.  The server is not required to send a response to the kernel.
 (D) The manager then transfers the data to the storeio server which
 eventually sends it to disk.  The device driver consumes the memory
 doing the equivalent of a `vm_deallocate`.
+
+
+# Issues
+
+  * [[open_issues/performance/io_system/read-ahead]]
+
+  * [[open_issues/performance/io_system/clustered_page_faults]]
+
+
+# GNU Hurd Usage
+
+Read about the [[Hurd's I/O path|hurd/io_path]].
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index 49a082e9..17dbe46f 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -34,3 +34,17 @@ IRC, freenode, #hurd, 2011-02-15
     <braunr> except for performance (because you can use larger - even very
       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
+
+    <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
+
+    <braunr> antrik: youpi added it for xen, yes
+    <braunr> antrik: but you're right, since mach uses a direct mapped kernel
+      space, the true problem is the lack of linux-like highmem support
+    <braunr> which isn't required if the kernel space is really virtual
diff --git a/microkernel/mach/memory_object.mdwn b/microkernel/mach/memory_object.mdwn
index 2342145c..f32fe778 100644
--- a/microkernel/mach/memory_object.mdwn
+++ b/microkernel/mach/memory_object.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2002, 2003, 2010, 2011 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -29,3 +29,5 @@ last one tried is the *default memory manager* that resides in the microkernel,
 in contrast to most of the others.  The default memory manager is needed
 because the microkernel can't wait infinitely for someone else to free the
 memory cache: it just calls the next memory manager hoping it to succeed.
+
+Read about [[GNU Mach's memory management|gnumach/memory_management]].