[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: Memory management details
From:       Terry Lambert <terry () lambert ! org>
Date:       1997-08-15 17:37:10
[Download RAW message or body]

> > That is a "bounded" project, that is pretty well understood, but just
> > not done yet.  I don't think that anyone has made any progress.  Not
> > to say that it is easy to do "right", but developing a properly
> > functioning swap on/ swap off a file is less risky than any of the above.
> > (The ONLY reason that we don't support swap-on directly, is that I don't
> > want to see it until we get a swap-off also.)  The swap-off is not
> > trivial, but isn't brain-surgery either.
> 
> Umm... I think I'm missing something here. You, John, should know most
> things in the VM category better then anyone, and you say we don't have
> it. Others say we do. What's the deal here?

The deal is that you can vnconfig a file as if it were a device,
and then swap on the "hosted" device ...effectively swapping on
a file.

So it's *possible* using the current codebase.

John is talking about "doing it right", where "swapon" takes a "-f"
and a file name argument and does all it needs to do itself.

John's right about the swap only being deconfigurable at reboot.

NeXTStep had a swapfile that would grow dynamically, which is
probably the ideal -- as long as you can bound the growth at
the top and bottom ends (like John implied).  But it also had
the "can't deconfigure" problem that John wants to overcome.

As he said, doing "the real thing" like he wants is trivial in
the "start" case, but will take work for the "stop" case.  How
do you drain a swap file that's in use?  It's a lot of work...


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

[prev in list] [next in list] [prev in thread] [next in thread]