Hi Ian, 


> Mike Cheponis <mac@Wireless.Com> writes:
>  > I think that "swap space reservation" and "DynaSwap" are completely
>  > compatible.  It's a matter of setting limits on just how much of the disk
>  > will be allowed for swap vs for files; think of it like a slider.
> 
>   > Currently, the slider is fixed...
> 
>I don't understand what you mean by "currently".

I mean that you decide on partition sizes when you init the disk.  My
"disklabel" reports in part:

  a:   108801       63     4.2BSD     1024  8192    16   # (Cyl.    0*- 107)
  b:   157248   108864       swap                        # (Cyl.  108 - 263)
  c:  4127697       63     unused        0     0         # (Cyl.    0*- 4094)
  d:  4127760        0     unused        0     0         # (Cyl.    0 - 4094)
  e:  3861648   266112     4.2BSD     1024  8192    16   # (Cyl.  264 - 4094)

I'm saying that I'd be happier with a simple /dev/disk0 entry, rather than
separate partitions.


>Amongst other thing disk partitions allow for different file systems
>optimized for different jobs (think of swap space as a special file
>system) and they allow for a crude but effective resource allocation
>policy.

>In the best of all possible worlds the it would be easy to change the
>amount of any resource allocated to a particular purpose be it memory
>disk or whatever. Furthermore it should be easy to customise an
>algorithm for doing it dynamically (hard limits being a special case
>of such an algorithm). In the case of disk space the allocation policy
>should place things to optimize performance.

Exactly!


>The problem is, doing all this is hard and the hard bit is not the
>implementation, it is the design. Unix has traditionally been pretty
>crude in terms of resource allocation (compared to say VMS which has
>quotas for pretty much every conceivable thing).  Few would argue that
>repartitioning disks is the ideal way of reallocating disk space
>between swap and file storage, and we now do have the means to swap to
>files (albeit with a performance penalty I presume).

I agree as well; yet I do think it's a worthy goal, as McKusick hopes, to
merge the VM system with the file system.

>Earlier in this thread you said that many things should be a matter of
>policy.  I agree with that, but the challenge is to come up with a
>easy and flexible means for administrators to implement that policy. At
>the same time the system should a) incur no significant loss of
>performance b) acceptable implementation complexity and c) is a
>sufficient improvement to warrant the effort.

Actually, Ian, I think that the system must perform *better* and be
at least as solid implementation-wise.

Unfortunately, for (c), I think that some construction is necessary to know
the answers for (a) and (b).

So I'm off thinking about how to do this, and any further input the bright
and experienced people on this list have for me is greatly appreciated.

-Mike