From owner-freebsd-current Mon Apr 23 23:26:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by hub.freebsd.org (Postfix) with ESMTP id D0B8C37B440 for ; Mon, 23 Apr 2001 23:26:53 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 5988016B7F for ; Tue, 24 Apr 2001 03:26:50 -0300 (EST) Received: (qmail 23700 invoked by uid 0); 24 Apr 2001 06:26:52 -0000 Received: from duckman.distro.conectiva (root@10.0.17.2) by burns.conectiva with SMTP; 24 Apr 2001 06:26:52 -0000 Received: from localhost (riel@localhost) by duckman.distro.conectiva (8.11.3/8.11.3) with ESMTP id f3O6Qni27128; Tue, 24 Apr 2001 03:26:49 -0300 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Tue, 24 Apr 2001 03:26:48 -0300 (BRST) From: Rik van Riel X-X-Sender: To: Alfred Perlstein Cc: , , Subject: Re: vm_mtx In-Reply-To: <20010423215131.D1790@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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