4e94f40222
the last accessed datum is moved to the root of the splay tree. Therefore, on lookups in which the hint resulted in O(1) access, the splay tree still achieves O(1) access. In contrast, on lookups in which the hint failed miserably, the splay tree achieves amortized logarithmic complexity, resulting in dramatic improvements on vm_maps with a large number of entries. For example, the execution time for replaying an access log from www.cs.rice.edu against the thttpd web server was reduced by 23.5% due to the large number of files simultaneously mmap()ed by this server. (The machine in question has enough memory to cache most of this workload.) Nothing comes for free: At present, I see a 0.2% slowdown on "buildworld" due to the overhead of maintaining the splay tree. I believe that some or all of this can be eliminated through optimizations to the code. Developed in collaboration with: Juan E Navarro <jnavarro@cs.rice.edu> Reviewed by: jeff |
||
---|---|---|
.. | ||
default_pager.c | ||
device_pager.c | ||
phys_pager.c | ||
pmap.h | ||
swap_pager.c | ||
swap_pager.h | ||
uma_core.c | ||
uma_dbg.c | ||
uma_dbg.h | ||
uma_int.h | ||
uma.h | ||
vm_contig.c | ||
vm_extern.h | ||
vm_fault.c | ||
vm_glue.c | ||
vm_init.c | ||
vm_kern.c | ||
vm_kern.h | ||
vm_map.c | ||
vm_map.h | ||
vm_meter.c | ||
vm_mmap.c | ||
vm_object.c | ||
vm_object.h | ||
vm_page.c | ||
vm_page.h | ||
vm_pageout.c | ||
vm_pageout.h | ||
vm_pageq.c | ||
vm_pager.c | ||
vm_pager.h | ||
vm_param.h | ||
vm_swap.c | ||
vm_unix.c | ||
vm_zeroidle.c | ||
vm.h | ||
vnode_pager.c | ||
vnode_pager.h |