From owner-freebsd-hackers Wed Oct 23 11: 8:35 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 27D4737B401 for ; Wed, 23 Oct 2002 11:08:34 -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 758F243E6A for ; Wed, 23 Oct 2002 11:08:33 -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 g9NI8WU7000444; Wed, 23 Oct 2002 11:08:32 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id g9NI8Hja000443; Wed, 23 Oct 2002 11:08:17 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 23 Oct 2002 11:08:17 -0700 From: David Schultz To: Matthew Dillon Cc: Peter Wemm , Sean Kelly , hackers@FreeBSD.ORG Subject: Re: swapoff? Message-ID: <20021023180817.GA354@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. 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