sticky bit

[John F. Haugh II]

In article <8724 at alice.UUCP> debra at alice.UUCP () writes:
>The theoretical argument for introducing the sticky bit is that loading a
>program from the swap-space is faster than loading it from the file-system.
>This is probably true because processes tend to be more or less contiguous
>in the swap-space whereas they in general are not contiguous in the file-
>system (especially not in older, swapping systems, for which the sticky-bit
>was developed). Unless a file is *really* scattered all over the disk this
>win is marginal.

This is quite definitely true.  The interface into the swap partition is
more or less `raw'.  A single read request is issued to bring the pure
text into memory [ This is modified by drive hardware, such as request
size limitations, and whether or not a read request may span tracks or
cylinders.  PDP-11 drives seemed to get this right. ]  This is vastly more
efficient than going through the file system.  Unfortunately it is a big
loser if there is a large .data segment.  The shell got around this by
putting the strings into the .text segment, thereby reducing the size of
the data segment.  And of course .bss takes little or no appreciable file
system reads ;-)  Proofs of this may be had by measuring file system
versus raw partition performance for reading.  And no cheating - BSD
systems don't count ;-)

The real win is to save a complete prototype on the swapper.  Or chunk
the old space heater and get a paging machine ;-)  I forget who brought
up the complete-prototype idea - but that's where the big win lies.
-- 
John F. Haugh II                        +-Quote of the Week:-------------------
VoiceNet: (214) 250-3311   Data: -6272  |"Now with 12 percent less fat than
InterNet: jfh at rpp386.Dallas.TX.US       | last years model ..."
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------