cvs commit: src/sys/amd64/include vmparam.h src/sys/arm/include vmparam.h src/sys/i386/include vmparam.h src/sys/ia64/include vmparam.h src/sys/kern kern_exec.c vfs_bio.c src/sys/powerpc/include vmparam.h src/sys/sparc64/include ...

[Andre Oppermann]

Alan Cox wrote:
> alc         2007-09-25 06:25:07 UTC
> 
>   FreeBSD src repository
> 
>   Modified files:
>     sys/amd64/include    vmparam.h 
>     sys/arm/include      vmparam.h 
>     sys/i386/include     vmparam.h 
>     sys/ia64/include     vmparam.h 
>     sys/kern             kern_exec.c vfs_bio.c 
>     sys/powerpc/include  vmparam.h 
>     sys/sparc64/include  vmparam.h 
>     sys/sun4v/include    vmparam.h 
>     sys/sys              vmmeter.h 
>     sys/vm               vm_contig.c vm_fault.c vm_map.c 
>                          vm_object.c vm_object.h vm_page.c 
>                          vm_page.h vm_pageout.c vm_pageq.c 
>                          vm_phys.c vm_phys.h 
>   Log:
>   Change the management of cached pages (PQ_CACHE) in two fundamental
>   ways:
>   
>   (1) Cached pages are no longer kept in the object's resident page
>   splay tree and memq.  Instead, they are kept in a separate per-object
>   splay tree of cached pages.  However, access to this new per-object
>   splay tree is synchronized by the _free_ page queues lock, not to be

I do not claim to have any specific VM knowledge or about the access
pattern on these trees.  What I've found however is that in most cases
splay trees are massive cache busters due to re-balancing on every
access (not just on every insert).  The only exception is in cases
where a very narrow working set out of a larger number of objects in
tree is in high use.  Otherwise red-black trees or for some sets hashes
tend to be much more cache efficient.  Just a almost random thought.

-- 
Andre