Date: Wed, 8 Jul 1998 01:57:08 -0400 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: Stefan Eggers <seggers@semyam.dinoco.de>, freebsd-hackers@FreeBSD.ORG Subject: Re: Someone working on swapoff? Message-ID: <9807080157.ZM4071@beatrice.rutgers.edu> In-Reply-To: Stefan Eggers <seggers@semyam.dinoco.de> "Someone working on swapoff?" (Jul 7, 9:56am) References: <199807070756.JAA07032@semyam.dinoco.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9807080157.ZM4071>