Sticky Bits (was: Re: WD1006 ...)

[John F. Haugh II]

In article <338 at ateng.UUCP> chip at ateng.UUCP (Chip Salzenberg) writes:
>According to james at bigtex.uucp (James Van Artsdalen):
>>Well, I don't recompile emacs too often, but perl, dist (does anyone
>>have dist working on SysVr3?) and the various news packages get
>>recompiled all the time ...
>
>WARNING:  MEMORY HOG ALERT:
>
>Some of the more frequently-used programs can have their load times reduced
>dramatically by setting the sticky bit (chmod +t).  This will load the
>program text once and leave it in memory, waiting for its next invocation.

what it really does is save the text image on the swapper when the job
exits.  normally, exit causes all system resources to be reclaimed,
such as memory and swap space.  the ISVTX bit (01000) in the permissions
causes the system to NOT reclaim the text image.  instead, the text
table entry is preserved and the inode table entry as well.  on the
next invocation, the system realizes the text portion has been loaded
already and proceeds to only load the data segment and zero the bss
segment.  hence, you see about a 50% improvement (assuming equal text
and data sizes) since the bss segment is zero filled and not loaded
from the disk file.  the is Yet Another Bit, the ITEXT bit (040), in
the inode table which is used in conjunction to indicate the inode in
question is a pure text prototype.  thus, the ISVTX bit WILL NOT WORK
if there is no pure text segment.  so compact model programs can't have
their sticky bits set effectively.

this works because the swapper in the old days used contigious blocks
on the swap device to save the image.  since there is only a seek
delay then a single huge transfer, swapping is much faster than file
system access.  things have probably changed since then, but the above
description should still hold up fairly well.  what this also means is
that if you have lots of save text files, your swap space requirements
go UP.
-- 
John F. Haugh II                 +--------- Cute Chocolate Quote ---------
HASA, "S" Division               | "USENET should not be confused with
UUCP:   killer!rpp386!jfh        |  something that matters, like CHOCOLATE"
DOMAIN: jfh at rpp386.uucp          |         -- apologizes to Dennis O'Connor