Subject: Re: paging space allocation (was Re: MFS over ISO-9660 union mounted
To: Chuck Silvers <email@example.com>
From: Mike Cheponis <mac@Wireless.Com>
Date: 05/14/1999 01:23:26
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. 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.
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