On Wed, Mar 15, 2000 at 06:13:24AM +1100, Simon Burge wrote:
> > >  * Is it possible to release individual pages in an aobj back to the
> > >    system?  This is one of the major problems with the current mfs (as
> > >    well as copying data multiple times).  If not, is there another sort
> > >    of uvm object that might be better suited to a swapfs?

check out uao_flush(... , PGO_FREE).


> > I think someone else suggested implementing it as one aobj per file.
> > I think this would be a better approach..
> > 
> > (among other things, it makes things like mmap of files in /tmp
> > potentially less painful..)
> 
> The idea crossed my mind, but this raises a few more (to my mind
> hairier) questions:
> 
>  * How quick is the process of creating an aobj?
> 
>  * Is there some kind of limit and/or performance impact of having lots
>    of aobjs?  This would seem to be a function of how well the pool
>    allocator can handle the load, and thus each aobj structure would
>    live in wired kernel memory.  This maybe even could lead to a DOS
>    attack if the circumstances were right and someone created lots of
>    files in the swapfs.
> 
>  * From an mmap POV, would this limit the maximum size of a file to the
>    size of swap (think sparse files)?

I'd recommend against the aobj-per-file idea, since as you point out,
this consumes much more wired kernel memory than aobj-per-filesystem.
the idea is that you'd like almost all of the memory used by the
mfs to be pushed out to swap if it's not being used.

the FFS disk layout is actually pretty decent for use in a swapfs, except that
FFS has no notion of being able to grow the underlying device (a swap-backed
virtual device in this case) when it runs out of space.  one approach would
be to enhance FFS this way (and also to call some device hook when it
frees a block), and then you'd get swapfs for a very small amount of
additional work.  also, this would pave the way for on-line growing of
disk-backed FFS filesystems.

-Chuck