Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Nov 2012 13:01:44 -0600
From:      Alan Cox <alc@rice.edu>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        Alan Cox <alc@FreeBSD.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r242941 - in head/sys: sys vm
Message-ID:  <50A29918.3000002@rice.edu>
In-Reply-To: <50A1FB96.3050300@freebsd.org>
References:  <201211130250.qAD2odEw065268@svn.freebsd.org> <50A1FB96.3050300@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/13/2012 01:49, Andre Oppermann wrote:
> On 13.11.2012 03:50, Alan Cox wrote:
>> Author: alc
>> Date: Tue Nov 13 02:50:39 2012
>> New Revision: 242941
>> URL: http://svnweb.freebsd.org/changeset/base/242941
>>
>> Log:
>>    Replace the single, global page queues lock with per-queue locks
>> on the
>>    active and inactive paging queues.
>
> Hear hear!  Now if only the cache-poisining splay tree would
> go as well...  I still have some patches that macrotize it
> so it can rather easily be replaced with something else, eg.
> an RB tree or such.
>

Honestly, this particular change is not going to have that much of an
effect.

For some time, in the machine-independent VM layer, the global page
queues lock had only been used as a lock on the active, inactive, and
hold page queues.  Aside from the page daemon, nothing in the
machine-independent VM layer acquired and held that lock for more than
the time it takes to enqueue or dequeue a single page.  There was no
reason to have an actual hold queue, so that queue was recently
eliminated.  The more consequential changes occurred from June to
October when I eliminated the use of the global page queues lock from
the various pmap implementations, except for PowerPC, which was done by
Nathan.  Some functions, notably pmap_remove_pages(), held the global
page queues lock for quite some time or were so frequently called,
notably pmap_enter(), that they created most of the contention for that
lock.

Right now, the primary issue that I see with the page queue locking is
that the page daemon can hold the lock on the active queue for a long
time.  This may block concurrent page faults from completing because
they must typically add the page to the active queue.  As for the
inactive queue, Kostik already made changes over the summer that now in
combination with this change prevent the page daemon from holding the
inactive queue lock for a long period of time.

As for the splay tree of pages in the VM object, Attilio has been
working on-and-off on a path-compressed trie implementation.  (The work
is in SVN under /user/attilio.)  I think it is more likely than not that
this work will be in 10.0 when it ships.

Alan




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A29918.3000002>