From owner-freebsd-hackers Tue Oct 8 4:36:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C8A337B401 for ; Tue, 8 Oct 2002 04:36:21 -0700 (PDT) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7182843E65 for ; Tue, 8 Oct 2002 04:36:20 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id g98BaJBY000434; Tue, 8 Oct 2002 04:36:19 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id g98BaE4n000433; Tue, 8 Oct 2002 04:36:14 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Tue, 8 Oct 2002 04:36:14 -0700 From: David Schultz To: Matthew Dillon Cc: Peter Wemm , Sean Kelly , hackers@FreeBSD.ORG Subject: Re: swapoff? Message-ID: <20021008113614.GA319@HAL9000.homeunix.com> Mail-Followup-To: Matthew Dillon , Peter Wemm , Sean Kelly , hackers@FreeBSD.ORG References: <20020713071911.GA1558@HAL9000.wox.org> <20020713073404.9869A3811@overcee.wemm.org> <20020713115746.GA2162@HAL9000.wox.org> <200207131636.g6DGaoqh081285@apollo.backplane.com> <20021007153845.GA371@HAL9000.homeunix.com> <200210072347.g97Nl3Zo049415@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210072347.g97Nl3Zo049415@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Rather than spamming the list with another 37K patch, I posted a revised version at http://csua.berkeley.edu/~das/swapoff.patch2 Thus spake Matthew Dillon : > The swap_pager_isswapped() function may not be doing > a sufficient test: [...] > It is quite possible for a VM page to be present but invalid, > meaning that the swap is still valid. You could incorrectly > return that the object is not swapped when in fact it is. > > BUT, since you only appear to be making this call on > the process's UPAGES object, there may not be a problem. > Perhapss the best thing to do is to not do the vm_page_lookup() > call and instead just unconditionally faultin() the uarea > if it looks like there might be a problem. I revised the patches to do as you suggested. It turns out that a couple of extra lines are needed, because when the scan over all processes restarts, pagein_all() will no longer automagically skip over processes it has already swapped in. It has to immediately free the swap metadata for the UPAGES object and dirty the associated pages (as opposed to letting swap_pager_swapoff do it); otherwise it will loop forever trying to swap in the same process. > You may need a master lock to ensure that only swapon() or > swapoff() is 'in progress' at any given moment. Added. (This was a deficiency in the original swapon() as well.) > The vm_page_grab() call below may block, I think: [...] > I think you may want to do the pip_add before calling vm_page_grab(). Yep, fixed. I also tweaked the calculation that determines whether there is enough virtual memory to remove the device, but it doesn't seem to detect when there is insufficient space. (I actually thought it was right the first time.) Can you see anything obviously wrong with my math? The code works fine in all of my tests, except that calling swapoff() when the system is under heavy paging load and has multiple swap devices sometimes leads to a few pages being missed by the scan. I think the problem is that some process allocates some swap and starts paging out just before the device is marked as off-limits. Am I missing a simple solution to this problem? (For now, I kludge around the issue by rescanning if there are still blocks remaining.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message