Date: Wed, 23 Oct 2002 11:08:17 -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: <20021023180817.GA354@HAL9000.homeunix.com> In-Reply-To: <200210141555.g9EFtoZh061812@apollo.backplane.com> References: <20020713115746.GA2162@HAL9000.wox.org> <200207131636.g6DGaoqh081285@apollo.backplane.com> <20021007153845.GA371@HAL9000.homeunix.com> <200210072347.g97Nl3Zo049415@apollo.backplane.com> <20021008113614.GA319@HAL9000.homeunix.com> <200210081745.g98Hjkam078883@apollo.backplane.com> <20021011130154.GA16549@HAL9000.homeunix.com> <200210111814.g9BIEbah040688@apollo.backplane.com> <20021014094217.GA228@HAL9000.homeunix.com> <200210141555.g9EFtoZh061812@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Matthew Dillon <dillon@apollo.backplane.com>: > :The concern was that there could be a race where the process is > :swapped out again after I have swapped it back in but before I can > :dirty its pages. (Perhaps I need to hold the process lock a bit > :longer.) Under heavy swapping load, swapoff() is failing to find > :a single page about one time out of ten, and I thought that might > :be the cause. > > Have you definitively tracked down the missing page? It > ought to be fairly easy to do from a kernel core with a > gdb macro. No, I've tested it extensively, and I haven't been able to reproduce the problem since I updated my sources. (It was hard to reproduce beforehand.) I did two more runs with one swap device and two runs with two swap devices, and it worked even when the system was thrashing. The latest patches are at http://www.CSUA.Berkeley.EDU/~das/swapoff.patch4 Performance is now much better when there are multiple swap devices. Instead of effectively having to wait for each hash chain to become quiescent, swapoff now skips busy objects, then does a complete rescan if it missed anything. Only a few rescans are required, even with multiple active swap devices. A clustering optimization might still be worthwhile, but that can be done another day. (Sorry for the delay in getting back to you. I've been too busy and sick for the last week to work on this.) 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?20021023180817.GA354>