On Sun, 16 May 1999, Jason Thorpe wrote:

>I've been sort of half-following this thread, and it's been giving me a
>lot of anxiety :-)
>
>"No, please, the pain has already stopped!"
>
>I remember, before we installed NetBSD 0.9C on the lab's hp300s, running
>various versions of HP-UX for the hp300 at the Ore. State CS department.
>HP-UX for the 300 didn't have any disk partitioning scheme (unlike HP-UX
>for the 800, which supported System V `slices').  So, in order to use
>swap space, you had to "swap to the end of the file system" (HP term for
>it).
>
>This caused SO much trouble.  On one machine, a 9000/360, which was the mail
>hub for the entire research network, the machine often croaked when the mailq
>got too large... no more space to swap out an in-core process to fire up
>another sendmail process.  It's not like we could just add more disks, either;
>we had a limited number of HP-IB 7958s :-)
>
>On the other hand, the undergrad network had a similar machine running
>NetBSD _0.9C_.  This machine seldom croaked; there was always enough room
>to swap something out, precisely because we didn't have that "swap to the
>end of the file system" ... ahem ... feature.
>
>Personally, I like the idea of being able to reserve these kinds of
>resources.  Especailly swap space; I mean, if you're using it, you're
>already encountering a resource shortage, by definition!  Best that your
>fallback mechanism be robust.


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 when you mkfs; but there is no reason that
the slider cannot be made dynamic, if desired.

Therefore, DynaSwap and "old style" swap are competely compatible!

This is the reason I don't understand why people are so vehemently opposed
to DynaSwap: It gives you everything that you have now, and it give me
(and others who are trying to solve large problems) additional flexibility.


Incidentally, about the resource shortage issue you mention, the way I
look it is that any code that's not running in L1 cache is pushing the
resource envelope; once it gets shoved into L2 cache, well, things really
get slow... and, gosh, if it gets shoved out to dram, well, that's waaay
slow, and, gulp, after that it goest to DynaSwap and after that...

Well, I was waiting to drop this on you guys, but the obvious next step is
to swap over the network.

Now, I know years ago Sun allowed you to do this over 10 Mb/s networks, but
the wisdom became that you don't swap over the net.  However, with 100 Mb/s
full duplex cards now really cheap and Gigabit ethernet cards becoming
available, I claim that swapping over net (to blazingly fast disks in a
server) is gonna be faster than swapping to a local IDE disk.  

(the back of the envelope numbers here are that a 5400 RPM Maxtor DiamondMax
series gives you about 100 Mb/s off the head; with that gigabit ethernet
card and a 10,000 RPM disk in the server on an unloaded network gives you
about 185 Mb/s throughput).

>         -- Jason R. Thorpe <thorpej@nas.nasa.gov>

I see everything to gain and nothing to lose by using DynaSwap.

-Mike