diff options
Diffstat (limited to 'open_issues/gnumach_memory_management.mdwn')
| -rw-r--r-- | open_issues/gnumach_memory_management.mdwn | 47 |
1 files changed, 46 insertions, 1 deletions
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index e5e9d2c5..46454207 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012, 2013 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 @@ -1026,6 +1027,9 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. < braunr> cache for kernel map entries in vm_map ? < braunr> the comment for mem_cpu_pool_get doesn't apply in gnumach, as there is no kernel preemption + +[[microkernel/mach/gnumach/preemption]]. + < braunr> "Don't attempt mem GC more frequently than hz/MEM_GC_INTERVAL times a second. < braunr> " @@ -2182,3 +2186,44 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. <braunr> also, i wrote the implementation in userspace, without functionality pmap provides (although i could have emulated it afterwards) + + +# IRC, freenode, #hurd, 2013-01-06 + + <youpi> braunr: panic: vm_map: kentry memory exhausted + <braunr> youpi: ouch + <youpi> that's what I usually get + <braunr> ok + <braunr> the kentry area is a preallocated memory area that is used to back + the vm_map_kentry cache + <braunr> objects from this cache are used to describe kernel virtual memory + <braunr> so in this case, i simply assume the kentry area must be enlarged + <braunr> (currently, both virtual and physical memory is preallocated, an + improvement could be what is now done in x15, to preallocate virtual + memory only + <braunr> ) + <youpi> Mmm, why do we actually have this limit? + <braunr> the kentry area must be described by one entry + <youpi> ah, sorry, vm/vm_resident.c: kentry_data = + pmap_steal_memory(kentry_data_size); + <braunr> a statically allocated one + <youpi> I had missed that one + <braunr> previously, the zone allocator would do that + <braunr> the kentry area is required to avoid recursion when allocating + memory + <braunr> another solution would be a custom allocator in vm_map, but i + wanted to use a common cache for those objects too + <braunr> youpi: you could simply try doubling KENTRY_DATA_SIZE + <youpi> already doing that + <braunr> we might even consider a much larger size until it's reworked + <youpi> well, it's rare enough on buildds already + <youpi> doubling should be enough + <youpi> or else we have leaks + <braunr> right + <braunr> it may not be leaks though + <braunr> it may be poor map entry merging + <braunr> i'd expected the kernel map entries to be easier to merge, but it + may simply not be the case + <braunr> (i mean, when i made my tests, it looked like there were few + kernel map entries, but i may have missed corner cases that could cause + more of them to be needed) |