| My point is simply this: if something is already on swap store, and
| hasn't changed, using its memory is as simple as throwing away its
| context and reverting to considering it stored on disk.  No physical
| disk rattling is required.

... until you need the page you threw away. :-)

Actually, in the quest to keep desfree memory available,
the pager could (might?)

	-- get rid of stale non-sharable pages from exited processes; then
	-- get rid of stale sharable pages with a zero reference count; then
	   [normal case of acquiring memory through pagedaemon's "LRU"]

As I said, throwing away something you might need later
seems wrong-headed to me.  

Running a slow constant GC to maintain a pool of available pages is
clearly a good thing for processes which grow out their address
spaces without reaching onto disk for pages, and this is
pretty common in lots of UNIX processes.

| So, if maybe extra pages could be written out in one quick operation
| while light paging is in progress (or, maybe when no normal paging is
| in progress), there might be a win when it comes time to find memory
| where the contents can be discared cheaply.

The only problem is that with the Mach VM, space is never
allocated in secondary storage until a page is migrated out to it.

Preallocating swap (or paging things out in antcipation of
wanting to do so later) limits the maximum amount of virtual
memory somewhat, and may be a poor anticipation; in many cases,
pages are created which will never migrate to secondary storage.

| Obviously you have far more knowledge of the actual VM than I do. :-)

It's dated.  For the past two years I've been hacking at a system
totally unlike UNIX, and I really need to UTSL alot when delving
into things changed by the Machification of 4BSD.  :)

| However, if I'm not mistaken, this is at least somewhat similar to
| some of the optimizations FreeBSD made.  I know John Dyson has done a
| considerable amount of work tuning the FreeBSD VM implementation to
| work well on modern hardware.

Yes, Dyson's stuff is clever.  I remember taking a look at it
after a discussion with him that stemmed out of something I was
talking to Paul Traina about when I was briefly toying with FreeBSD
on a really unusual Intel-based laptoy.  I dunno if it's changed
much recently, though.

I have an old allergy to a merged VM/buffer cache mostly because
of SunOS 4.1.x's real problems when trying to do things with big
processes on boxes that are really busy filesystem-wise
(like news or UUCP boxes).  This is certainly an idiosyncracy,
as I get ridiculous amounts of mail (I treat it all as news, whenever
possible) and occasionally like to do things to large amounts of it
and I tend to run really large processes too...

	Sean.