Date: Tue, 24 Apr 2001 03:26:48 -0300 (BRST) From: Rik van Riel <riel@conectiva.com.br> To: Alfred Perlstein <bright@wintelcom.net> Cc: <current@FreeBSD.ORG>, <jhb@FreeBSD.ORG>, <jake@FreeBSD.ORG> Subject: Re: vm_mtx Message-ID: <Pine.LNX.4.33.0104240321570.17635-100000@duckman.distro.conectiva> In-Reply-To: <20010423215131.D1790@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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). 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... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ 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?Pine.LNX.4.33.0104240321570.17635-100000>