From owner-freebsd-hackers Wed Jul 8 02:06:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA00558 for freebsd-hackers-outgoing; Wed, 8 Jul 1998 02:06:07 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA00541 for ; Wed, 8 Jul 1998 02:06:03 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) id BAA04073; Wed, 8 Jul 1998 01:57:08 -0400 (EDT) From: "Allen Smith" Message-Id: <9807080157.ZM4071@beatrice.rutgers.edu> Date: Wed, 8 Jul 1998 01:57:08 -0400 In-Reply-To: Stefan Eggers "Someone working on swapoff?" (Jul 7, 9:56am) References: <199807070756.JAA07032@semyam.dinoco.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Stefan Eggers , freebsd-hackers@FreeBSD.ORG Subject: Re: Someone working on swapoff? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 7, 9:56am, Stefan Eggers (possibly) wrote: > Hi! > > Is there still anybody left working on swapoff? The only reference I > have in my mail archive is a mail from John mentioning this briefly > ("when I get swapoff working"). Now that he left the project does > anybody know what happened to this? > > It is really cruel to have to reboot a machine just because one uses a > swap file on a non-root filesystem and can't get back to multi user > from single user because the "mount -a" complains that the filesystem > is busy. And besides this I think there's something missing with this > asymmetry. Would just look more complete with it. :-) While I've been looking at this problem (and related ones, such as the idea of a swap device (using swapping via the vnode driver) that can expand and contract as necessary - put it on an MFS and the MFS effectively just got the ability to expand and contract) on and off, I have neither the time nor the experience with C needed for solving it. What it looks like is necessary is the following: A. an rlist_remove or whatever (put in kern/subr_rlist.c) that is capable of removing a specified resource list entry; this would be called multiple times (ideally, make it a macro or inline) to remove each of the entries associated (in vm/vm_swap.c's swaponvp's call of rlist_free) with the given swap device - ideally, one that could remove from the list entry only the last portion, for maximal flexibility with the aforementioned idea of expandable and contractable swap devices; B. either keeping track of the object entries associated with a given rlist entry (via a list associated with the rlist entry, allocated via a modified rlist_alloc - rlist_obj_alloc, perhaps? - in vm/swap_pager.c's swap_pager_getswappages), or a search through the swap_pager_object_list for objects occupying the given swap space; the former would take more memory, the latter would take more time; given today's relatively cheap memory, and that some kernel memory may be freeable by making some currently wired memory pageable (look at sys/malloc.h for a list of some memory types - most of the NFS stuff seems possible, for instance, so long as you're not swapping to it), I'd say the former is preferable; one would then do a swap_pager_getpages for each of the objects and pages that were on the swap device in question, fetching them into memory, followed by a swap_pager_putpages to put them back out onto another swap device (perhaps with a check to make sure nothing was waiting on the page in question - then do a wakeup instead, unless there was a swap space crunch). One thing that would be nice in all of this is to add a priority field to the rlist entries, or better yet multiple rlists for swap, with the kern/subr_rlist.c stuff being bright enough to check in order of priority. That way: A. somebody could have emergency swapping over NFS, with it only used if other swap space fills up - thus avoiding network latency et al; B. vnode pager swap space, which is less efficient than direct device swapping, could be used only after other swap space was used up; C. in my idea of expandable/contractable swap space, these could be used only after dedicated swap space filled up, thus maximizing effectiveness of disk space usage; and D. in your situation, swap devices you were wanting to later deallocate could be used last, resulting in less objects to swap in and out. The rlist stuff isn't currently used except in vm, at least in -stable, so changing it shouldn't pose any problems. > As I am at it: Any hints on good books, papers, whatever about paging > and swapping internals in BSD - especially FreeBSD? I'd be curious about this also; the existing information that I've found (in the 4.4 BSD book) is not exactly copious, and is somewhat outdated. -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message