* Rik van Riel <[EMAIL PROTECTED]> [010423 23:27] wrote:
> On Mon, 23 Apr 2001, Alfred Perlstein wrote:
> > requires vm_page_queues_mtx:
> >  manipulation of vm_page_queues
> [snip]
> > pmaps spotted:
> > pmap_copy_page
> > pmap_page_protect
> There is potential for nasty lock ordering conflicts here.
> Page faults will go    vm_mtx -> vm_page_queues_mtx
> The pageout code goes  vm_page_queues_mtx -> vm_mtx

Actually vm_page_queues_mtx == vm_mtx.  At a later date I may look
at finegraining the vm_mtx down a bit, as it stands there was a
lot of code that manipulates flags inside of vm_pages and vm_objects
by using atomic ops.  Obviously this works ok when there's only
one consumer but it's really expensive to do so and would probably
do a lot better under a single mutex.

> Alternatively, the pageout code is all under the vm_mtx,
> during the whole duration, but that would lock out the
> other CPUs during a potentially long time.
> It would also mean the kernel needs to have 2 versions
> of all the pmap functions ... one where the vm_mtx is
> already taken and one that needs to take the vm_mtx by
> itself (the alternative, fixing all the callers, is
> probably worse).

Fixing callers makes more sense from a performance standpoint,
basically there's probably signifigant amounts of code that
expects the vm not to change out from under it in between calls
into the vm.

> An alternative could be to use trylock functions and
> let the pageout code back off whenever somebody is in
> a page fault. This will work because eventually all the
> page faulters will be waiting for free memory and none
> of them has any of the VM locks...

Well right now we're SOL on all sides, but honestly with it all
still under Giant the performance is OK, if we're able to lock down
a major subsystem we can only expect performance to get better.

Anyhow, at this point i'm more interested in people stepping up
with diffs rather than discussing my current broken ones. :)

-Alfred Perlstein - [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to