Date: Mon, 23 Apr 2001 23:51:10 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Rik van Riel <riel@conectiva.com.br> Cc: current@FreeBSD.ORG, jhb@FreeBSD.ORG, jake@FreeBSD.ORG Subject: Re: vm_mtx Message-ID: <20010423235110.F1790@fw.wintelcom.net> In-Reply-To: <Pine.LNX.4.33.0104240321570.17635-100000@duckman.distro.conectiva>; from riel@conectiva.com.br on Tue, Apr 24, 2001 at 03:26:48AM -0300 References: <20010423215131.D1790@fw.wintelcom.net> <Pine.LNX.4.33.0104240321570.17635-100000@duckman.distro.conectiva>
next in thread | previous in thread | raw e-mail | index | archive | help
* Rik van Riel <riel@conectiva.com.br> [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 - [alfred@freebsd.org] 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010423235110.F1790>