From owner-freebsd-current@FreeBSD.ORG Sat Sep 25 17:56:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FFFD16A4CE; Sat, 25 Sep 2004 17:56:38 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADC0B43D39; Sat, 25 Sep 2004 17:56:37 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i8PHujYS000859; Sat, 25 Sep 2004 13:56:45 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i8PHujeQ000858; Sat, 25 Sep 2004 13:56:45 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 25 Sep 2004 13:56:45 -0400 From: David Schultz To: Pawel Jakub Dawidek Message-ID: <20040925175645.GA819@VARK.MIT.EDU> Mail-Followup-To: Pawel Jakub Dawidek , Jun Kuriyama , Current References: <7m7jqjhojv.wl@black.imgsrc.co.jp> <20040924122508.GG9550@darkness.comp.waw.pl> <20040924161255.GA699@VARK.MIT.EDU> <20040925095734.GI9550@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040925095734.GI9550@darkness.comp.waw.pl> cc: Jun Kuriyama cc: Current Subject: Re: panic: swap_pager_isswapped: failed to locate all swap meta blocks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2004 17:56:38 -0000 On Sat, Sep 25, 2004, Pawel Jakub Dawidek wrote: > On Fri, Sep 24, 2004 at 12:12:56PM -0400, David Schultz wrote: > +> One way to speed it up would be to wait until after most userland > +> processes have been killed, since most of the data won't need to > +> be swapped back in in that case. In fact, this is an improvement > +> for another reason, namely, there might not be enough physical > +> memory for swapoff() to work otherwise. > > I'm not really aware how to define rcNG scripts order on shutdown. > We can also move swapoff to kernel to be called even after all file > systems are unmounted. Yep, doing it in the kernel is what I was thinking. If you wait until all the userland processes are gone, swapoff() should be practically free. Another option would be to add some magic involving the SW_CLOSING flag, which indicates to the swap subsystem that nothing should be swapped to a given device in addition to what's already there. After setting the flag and waiting for any outstanding putpages() operations to complete, I believe the underlying device could be downgraded to read-only safely without swapping anything back in. But interlocking with putpages() might be more trouble than it's worth.