Date: Tue, 8 Oct 2002 04:36:14 -0700 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Wemm <peter@wemm.org>, Sean Kelly <smkelly@zombie.org>, hackers@FreeBSD.ORG Subject: Re: swapoff? Message-ID: <20021008113614.GA319@HAL9000.homeunix.com> In-Reply-To: <200210072347.g97Nl3Zo049415@apollo.backplane.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <dillon@apollo.backplane.com>: > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021008113614.GA319>