Merge remote-tracking branch 'fp/master'

2 files changed, 66 insertions, 3 deletions

diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index f15c4d25..448aafcc 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -894,3 +894,32 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> ok
     <braunr> it's tricky
     <braunr> mcsim: try to find where the first use of the allocator is made
+
+
+# IRC, freenode, #hurd, 2011-07-22
+
+    <mcsim> braunr, hello. Kernel with your allocator already compiles and
+      runs. There still some problems, but, certainly, I'm on the final stage
+      already. I hope I'll finish in a few days.
+    <tschwinge> mcsim: Oh, cool!  Have you done some measurements already?
+    <mcsim> Not yet
+    <tschwinge> OK.
+    <tschwinge> But if it able to run a GNU/Hurd system, then that already is
+      something, a big milestone!
+    <braunr> nice
+    <braunr> although you'll probably need to tweak the garbage collecting
+      process
+    <mcsim> tschwinge: thanks
+    <mcsim> braunr: As back-end for allocating memory I use
+      kmem_alloc_wired. But in zalloc was an opportunity to use as back-end
+      kmem_alloc_pageable. Although there was no any zone that used
+      kmem_alloc_pageable. Do I need to implement this functionality?
+    <braunr> mcsim: do *not* use kmem_alloc_pageable()
+    <mcsim> braunr: Ok. This is even better)
+    <braunr> mcsim: in x15, i've taken this even further: there is *no* kernel
+      vm object, which means all kernel memory is wired and unmanaged
+    <braunr> making it fast and safe
+    <braunr> pageable kernel memory was useful back when RAM was really scarce
+    <braunr> 20 years ago
+    <braunr> but it's a source of deadlock
+    <mcsim> Indeed. I'll won't use kmem_alloc_pageable.
diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn
index 37433e06..9e20f8e1 100644
--- a/open_issues/performance/io_system/clustered_page_faults.mdwn
+++ b/open_issues/performance/io_system/clustered_page_faults.mdwn
@@ -12,7 +12,10 @@ License|/fdl]]."]]"""]]
 
 [[community/gsoc/project_ideas/disk_io_performance]].
 
-IRC, freenode, #hurd, 2011-02-16
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-02-16
 
     <braunr> exceptfor the kernel, everything in an address space is
       represented with a VM object
@@ -88,9 +91,8 @@ IRC, freenode, #hurd, 2011-02-16
     <braunr> recommend*
     <etenil> ok
 
----
 
-IRC, freenode, #hurd, 2011-02-16
+# IRC, freenode, #hurd, 2011-02-16
 
     <antrik> etenil: OSF Mach does have clustered paging BTW; so that's one
       place to start looking...
@@ -103,3 +105,35 @@ IRC, freenode, #hurd, 2011-02-16
       can serve as a starting point
 
 <http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html>
+
+
+# IRC, freenode, #hurd, 2011-07-22
+
+    <braunr> but concerning clustered pagins/outs, i'm not sure it's a mach
+      interface limitation
+    <braunr> the external memory pager interface does allow multiple pages to
+      be transfered
+    <braunr> isn't it an internal Mach VM problem ?
+    <braunr> isn't it simply the page fault handler ?
+    <antrik> braunr: are you sure? I was under the impression that changing the
+      pager interface was among the requirements...
+    <antrik> hm... I wonder whether for pageins, it could actually be handled
+      in the pages instead of Mach... though this wouldn't work for pageouts,
+      so probably not very helpful
+    <antrik> err... in the pagers
+    <braunr> antrik: i'm almost sure
+    <braunr> but i've be proven wrong many times, so ..
+    <braunr> there are two main facts that lead me to think this
+    <braunr> 1/
+      http://www.gnu.org/software/hurd/gnumach-doc/Memory-Objects-and-Data.html#Memory-Objects-and-Data
+      says lengths are provided and doesn't mention the limitation
+    <braunr> 2/ when reading about UVM, one of the major improvements (between
+      10 and 30% of global performance depending on the benchmarks) was
+      implementing the madvise semantics
+    <braunr> and this didn't involve a new pager interface, but rather a new
+      page fault handler
+    <antrik> braunr: hm... the interface indeed looks like it can handle
+      multiple pages in both directions... perhaps it was at the Hurd level
+      where the pager interface needs to be modified, not the Mach one?...
+    <braunr> antrik: would be nice wouldn't it ? :)
+    <braunr> antrik: more probably the page fault handler