diff options
Diffstat (limited to 'open_issues/gnumach_memory_management.mdwn')
| -rw-r--r-- | open_issues/gnumach_memory_management.mdwn | 65 |
1 files changed, 57 insertions, 8 deletions
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index a5dd6955..f15c4d25 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -12,7 +12,10 @@ License|/fdl]]."]]"""]] There is a [[!FF_project 266]][[!tag bounty]] on this task. -IRC, freenode, #hurd, 2011-04-12: +[[!toc]] + + +# IRC, freenode, #hurd, 2011-04-12 <antrik> braunr: do you think the allocator you wrote for x15 could be used for gnumach? and would you be willing to mentor this? :-) @@ -597,7 +600,8 @@ IRC, freenode, #hurd, 2011-04-12: <mcsim> It would be better to rewrite it using debugfs, but when I was writing this test I didn't know about trace_* macros -2011-04-15 + +# IRC, freenode, #hurd, 2011-04-15 <mcsim> There is a hack in zone_gc when it allocates and frees two vm_map_kentry_zone elements to make sure the gc will be able to allocate @@ -632,7 +636,8 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> i think that's why i have "sources" in my slab allocator, the default source (vm_kern) and a custom one for kernel map entries -2011-04-18 + +# IRC, freenode, #hurd, 2011-04-18 <mcsim> braunr: you've said that once page is completely free, it is returned to the vm. @@ -640,7 +645,8 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> mcsim: i also said i was wrong about that <braunr> zone_gc is the only one -2011-04-19 + +# IRC, freenode, #hurd, 2011-04-19 <braunr> antrik: mcsim: i added back a new per-cpu layer as planned <braunr> @@ -649,7 +655,8 @@ IRC, freenode, #hurd, 2011-04-12: loops, just as in zone_gc, to reduce contention and avoid deadlocks <braunr> this is really common in memory allocators -2011-04-23 + +# IRC, freenode, #hurd, 2011-04-23 <mcsim> I've looked through some allocators and all of them use different per cpu cache policy. AFAIK gnuhurd doesn't support multiprocessing, but @@ -661,7 +668,8 @@ IRC, freenode, #hurd, 2011-04-12: <antrik> I'm not sure I suggested that explicitly to you; but probably it makes most sense to use that in gnumach -2011-04-24 + +# IRC, freenode, #hurd, 2011-04-24 <mcsim> antrik: Yes, I have. He uses both global and per cpu caches. But he also suggested to look through slqb, where there are only per cpu @@ -773,7 +781,8 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> the fact that the kernel allocator uses virtual memory doesn't mean the kernel has no mean to allocate contiguous physical memory ... -2011-05-02 + +# IRC, freenode, #hurd, 2011-05-02 <braunr> hm nice, my allocator uses less memory than glibc (squeeze version) on both 32 and 64 bits systems @@ -822,7 +831,8 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> it could also be used to drop the overloaded (and probably over imbalanced) page cache hash table -2011-05-03 + +# IRC, freenode, #hurd, 2011-05-03 <mcsim> antrik: How should I start porting? Have I just include rbraun's allocator to gnumach and make it compile? @@ -845,3 +855,42 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> there is work to be done ;) <braunr> (not to mention the obvious about replacing all the calls to the zone allocator, and testing/debugging afterwards) + + +# IRC, freenode, #hurd, 2011-07-14 + + <braunr> can you make your patch available ? + <mcsim> it is available in gnumach repository at savannah + <mcsim> tree mplaneta/libbraunr/master + <braunr> mcsim: i'll test your branch + <mcsim> ok. I'll give you a link in a minute + <braunr> hm why balloc ? + <mcsim> Braun's allocator + <braunr> err + <braunr> + http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=kern/kmem.c;h=37173fa0b48fc9d7e177bf93de531819210159ab;hb=HEAD + <braunr> mcsim: this is the interface i had in mind for a kernel version :) + <braunr> very similar to the original slab allocator interface actually + <braunr> well, you've been working + <mcsim> But I have a problem with this patch. When I apply it to gnumach + code from debian repository. I have to make a change in file ramdisk.c + with sed -i 's/kernel_map/\&kernel_map/' device/ramdisk.c + <mcsim> because in git repository there is no such file + <braunr> mcsim: how do you configure the kernel before building ? + <braunr> mcsim: you should keep in touch more often i think, so that you + get feedback from us and don't spend too much time "off course" + <mcsim> I didn't configure it. I just run dpkg-buildsource -b. + <braunr> oh you build the debian package + <braunr> well my version was by configure --enable-kdb --enable-rtl8139 + <braunr> and it seems stuck in an infinite loop during bootstrap + <mcsim> and printf doesn't work. The first function called by c_boot_entry + is printf(version). + <braunr> mcsim: also, you're invited to get the x15mach version of my + files, which are gplv2+ licensed + <braunr> be careful of my macros.h file, it can conflict with the + macros_help.h file from gnumach iirc + <mcsim> There were conflicts with MACRO_BEGIN and MACRO_END. But I solved + it + <braunr> ok + <braunr> it's tricky + <braunr> mcsim: try to find where the first use of the allocator is made |