diff options
| -rw-r--r-- | open_issues/gnumach_memory_management.mdwn | 29 | ||||
| -rw-r--r-- | open_issues/performance/io_system/clustered_page_faults.mdwn | 40 |
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 |