Date: Tue, 15 Oct 2002 00:11:03 -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: <20021015071103.GA2394@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. I haven't figured out gdb macros yet, and I'm kinda busy throughout the week, but I'll try to track down the page this weekend. > This sounds reasonable, it's certainly worth a shot. Another > thing you may be able to do is to try to cluster the pageins > on an object-by-object basis since our swap-scanning is > probably resulting in having to wait for the PIP count of > the same object many times (for large objects with lots of > swap blocks). > > Hmm. Since we have to track down every swap block and we can > (do?) get a count of pages that need to be swapped in, we could > remove the PIP wait code and simply loop on the swap hash table > over and over again until we've found all the swap blocks that > we know have been allocated to that device. Or something like that. The latter idea was more or less what I had in mind. The only catch is that you have to wait at least once for each pass or you'll never give up the processor. It solves the basic problem with the current approach, which is that you get livelock if there's too much swapping activity to other swap devices. 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?20021015071103.GA2394>