Subject: Re: paging space allocation (was Re: MFS over ISO-9660 union mounted with no swap space?)
To: Mike Cheponis <mac@Wireless.Com>
From: Chuck Silvers <firstname.lastname@example.org>
Date: 05/14/1999 05:38:33
Mike Cheponis writes:
> > 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.
a growable and shrinkable file can also use as much or as little
of the disk as needed, and it fits much better within the filesystem model.
> >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?
what is not "dynamic" about adding blocks to a file?
> > 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.
but if you defrag the file, then you can't use that space for paging anymore.
so the next time someone used that file, you wouldn't be able to put paging
space near it. so doesn't defraging the space used by files conflict
with putting paging space near files you're using?