Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!uxc!iuvax!rutgers!att!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.wizards
Subject: Re: sticky bit
Message-ID: <8724@alice.UUCP>
Date: 10 Jan 89 21:46:27 GMT
References: <18016@adm.BRL.MIL> <14750@cisunx.UUCP> <1359@mtunb.ATT.COM> <314@twwells.uucp>
Reply-To: debra@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 34

In article <314@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes:
>... [arguments about sticky bit deleted]
>
>I just did my editor, compiler, make, and ls.  That seems to be
>sufficient.
>
Sufficient for what? I have run several tests on different systems, both
with and without virtual memory, and have never found any improvement by
setting the sticky bit for any program.

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.

However, on most older systems setting the sticky bit implies that when
the last process executing the program exits the program text has to be
"swapped out", which takes time. One needs many slightly faster invokations
to compensate for this extra (one-time only) swap-out time.
Now, some newer systems don't actually swap out the text but keep it in
memory if possible. In that case there may be a win.

Considering the annoying side-effects of sticky-bit programs (you cannot
overwrite them easily, you cannot unmount file systems, etc) I would not
recommend using the sticky bit anymore.

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------