From owner-cvs-src@FreeBSD.ORG Tue Sep 25 12:01:35 2007 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B2A816A418 for ; Tue, 25 Sep 2007 12:01:35 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 604EF13C494 for ; Tue, 25 Sep 2007 12:01:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 57096 invoked from network); 25 Sep 2007 11:18:42 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Sep 2007 11:18:42 -0000 Message-ID: <46F8F26C.50709@freebsd.org> Date: Tue, 25 Sep 2007 13:35:08 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Alan Cox References: <200709250625.l8P6P7w7082233@repoman.freebsd.org> In-Reply-To: <200709250625.l8P6P7w7082233@repoman.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: 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 ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2007 12:01:35 -0000 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