On Thu, 13 May 1999, Chuck Silvers wrote:

> when I first started working in the CS dept back at CMU 9 years ago,
I worked CMU 1981-1986, then at MIT in 1986-87 on BSD 4.[123] doing
real-time unix drivers for h/w I had built, and VM hacks to support
legged locomotion, w/big data collection arrays,in the Leg Lab.


> the version of mach in use on department machines at that point
> had exactly the feature you describe, using free inodes to store
> paging space.  the next version switched to representing the paging
> space in a filesystem as a single file, but unlike the current netbsd
> "swap files", the file could be grown on demand by the vm system.
> later, mach 3 went to preallocated, non-growable paging files like
> we have in netbsd today.
> 
> the anonymous-space version doesn't have any real advantage over the
> growable file scheme as far as I'm concerned, but the ability to
> lazily allocate the backing store for paging space from the filesystem
> is pretty cool.

anon-space (I call it DynaSwap) allows VM to use as much or as little of
the disk as needed; this seems like a significant benefit.


>the mach scheme had hi- and lo-watermarks, so you
> could guarantee a certain amount of paging space was always available
> and also that a memory pig process wouldn't (necessarily) fill
> your filesystem.  setting the watermarks to the same value resulted
> in the current preallocation situation.

I remember only vaguely some of the Mach stuff, and I do recall a really
good team worked on it, and they had plenty of decent ideas.  I wonder why
they abandoned dynamic swap space?

 
> the notion of putting swap space near files currently in use is
> interesting.  wouldn't this result in the space used for actual files
> becoming fragmented by the little bits of paging space interspersed, tho?

I think this would be OK, especially if once the process using the pages
finishes, and the space becomes deallocated.  A background defragger can
then defrag the file.


>as for keeping all of the info on paging space in a filesystem in memory,
>would there be any advantage to doing that vs. just putting the paging space
>in a file?  keeping it all in memory could consume considerable amounts
>of RAM, especially if the space all in little pieces near currently used
>files. a file containing paging space would survive a crash just as well as
>any other file in the filesystem.

You're of course right that for huge processes the in-memory bookkeeping
could be substantial, because it would use not only the allocation bit
vector but tables of page table assocations.  Clearly, -this- info must
be able to be swapped out if necessary, too.


> this is all a separate discussion from the previous subject tho, since
> eager vs. lazy allocation of paging space to back virtual memory allocations
> is only somewhat related to how paging space is allocated on disk.
> 
> -Chuck

Right. Thanks for that observation.


I'm thinking of what it'll take to have unix let me have these wonderful
abstractions in userland, all being supported by kernel-mode structures
that let me forget as much as possible about the actual resources on a machine.

I really don't want to worry about my computer; I want my computer to worry
about me(!).


-Mike