> IMHO, we should have a mechanism, that allows us to mark a certain
> swap partition for removal. Then try to move all allocated pages
> into memory and have the kernel/pagedaemon allocate a different
> page on different swap space, thus freeing the marked partition

That would be cool.

> However, I think your approach doesn't scale well. Imagine the overhead
> to walk through the list of possible swap files for lots of swap files/

The conceptual description is not necessarily the implementation...

I didn't want to complicate the first post by talking about how the
eligible swap file lists would be managed. Now that I think about it,
the flexibility of group membership would be difficult to represent
compactly. How about this:

All processes owned by a given user (ignoring setuid magic) share a
refcounted list of swapfiles that are accessible via user permissions.
Same with group id's (meaning we only allow group access via your primary
group). Also have one 'other' list shared by the whole system.

When swap files are mounted/unmounted or their permissions change (maybe
we should just rely on your "migrate out of this swap file" operation and
not allow _any_ user changes to a swap file while mounted), we scan the
lists and touch them up. But during page allocation, our search is bounded
by the actual set of swap files that _could_ be accessed by this user if
the swap files all had at least one free page each. Finally, if we split
each list into full/not-full halves, then the search for a new page becomes
a check for the first node of each list: user, group, other. If all three
lists are empty (everything's on the full 'half' of the list) then sorry!

The above algorithm extends to full group membership, but maintaining the
internal representation of /etc/group is almost certainly more trouble than
it's worth. Or is it? Anyway, switching gears a little:

I think it makes sense for the system to remember no more than one primary
swap file for each user: when you log out, your swap files get unmounted,
and when you log back in, that one primary swap file is always mounted
automatically (this also primes the refcounted list of swap files accessible
via your userid and maybe your group id, when you first log in).

This all sounds pretty feasible to me, except that we have to catch all cases
where "a new user has entered the system" so we can prime his list; we also
need to make sure that whenever a process changes identity legitimately via
su(1), it attaches itself to the list for that user -- that might be a little
slow unless we spend a hash table of pointers to list-heads. Same for group.

Note: I don't plan to push for this (and thereby volunteer myself for the job)
-- I am more interested in establishing whether it can be done cleanly and
still have all the properties I think it would need to have.

Todd Whitesel
toddpw @ best.com