From owner-freebsd-hackers Tue Oct 15 0:11: 8 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 B4EF637B401 for ; Tue, 15 Oct 2002 00:11:06 -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 D97D143EA9 for ; Tue, 15 Oct 2002 00:11:05 -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 g9F7B4jf002466; Tue, 15 Oct 2002 00:11:04 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id g9F7B3em002465; Tue, 15 Oct 2002 00:11:03 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Tue, 15 Oct 2002 00:11:03 -0700 From: David Schultz To: Matthew Dillon Cc: Peter Wemm , Sean Kelly , hackers@FreeBSD.ORG Subject: Re: swapoff? Message-ID: <20021015071103.GA2394@HAL9000.homeunix.com> Mail-Followup-To: Matthew Dillon , Peter Wemm , Sean Kelly , hackers@FreeBSD.ORG 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210141555.g9EFtoZh061812@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 Thus spake Matthew Dillon : > :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