Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!sri-spam!mordor!lll-crg!seismo!nbires!vianet!cprice
From: cprice@vianet.UUCP (Charlie Price)
Newsgroups: net.unix-wizards
Subject: Re: sticky bit obsolete?
Message-ID: <19@vianet.UUCP>
Date: Fri, 8-Aug-86 17:03:52 EDT
Article-I.D.: vianet.19
Posted: Fri Aug  8 17:03:52 1986
Date-Received: Sun, 10-Aug-86 20:03:47 EDT
References: <16@vianet.UUCP>
Organization: ViaNetix, Inc., Boulder, CO
Lines: 57

>   Here is a question to people porting UNIX (and derivatives) to fast
> machines:  is the sticky bit idea worthwhile?   That is, on machines
> with slow disks it was worth keeping the text in the swap area, but,
> with faster disks and more memory, has the sticky bit become obsolete?

To add some incentive for a discussion here, the most recent
System V Interface Definition, Issue 2 (the two-volme set),
(Bob hasn't seen this, by the way) has a change for the definition of
access permission bits for a file.  For CHMOD(BA_OS) (chmod system call):
  "Issue 1 identified the access permission bit 01000 as "save text
  image after execution"; Issue 2 indicates it as "reserved"".
Everywhere else I've seen they have changed every description of the
permission bit 01000 to "reserved".
I think this means that a conforming implementation CAN'T use that
access bit to mean anything -- does anyone have a different interpretation?

I think that the management of disk storage for executable images
and page/swap storage is a critical issue in performance for small systems
or any system with a high "exec()" rate.  I also think that there is no
single strategy that is best for a large chunk of the range of these systems.

One particular example I'm familiar with is a LARGE text
edit/processing program running on a 4.2/68010 system with a small, slow disk
(and a fairly small memory).
Larger or faster hardware isn't really an option -- and you always
have applications that are pushing the hardware they are on.
The program initialization uses a lot of the functions once, or at least
uses functions throughout the text, and it touches/initializes
a lot of the static data, too.  The time before the user ever gets
a chance to do anything is huge -- more than 30 seconds.
In this case, improving the startup behavior would have a large
effect on customer satisfaction (and, one assumes, profit!).

One problem, changed in some implementations of 4.n, is that text pages
are first sucked in from the executable and immediately moved out
to page space.  If it were possible to page in shared text from
the executable all the time, it would eliminate the need for the
the blocks in the page area and the extra traffic for the pageouts
(that moves the sllooowwww head-arm on the single disk all over the place).
[Of course, now you have the problem of paging possibly-smaller chunks
from wherever they are on the disk.  Like I said, the problem is changed.]
If the page space isn't a critical problem then retaining the text
image in page space would eliminate the extra traffic for page outs
and maybe (perhaps, possibly) allow more effective page in by
klustering (or is it clustering?) storage.

If you have a swapable executable, it can be a LOT faster to swap
it in from contiguous storage than read it a chunk at a time
from wherever it lands in the filesystem.  The slower the access time
of the disk, the more difference you can see from this.

Until systems offer better management tools to assist program startup
I think that an (advisory) sticky bit is a useful thing to have.

-- 
Charlie Price    {hao stcvax nbires}!vianet!cprice    (303) 440-0700
ViaNetix, Inc. / 2900 Center Green Ct. South / Boulder, CO   80301