devine@vianet.UUCP (Bob Devine) (08/08/86)
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? Bob
chris@umcp-cs.UUCP (Chris Torek) (08/08/86)
In article <16@vianet.UUCP> devine@vianet (Bob Devine) writes: >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? As to that I cannot say; but it is perhaps worth noting that 4.3 now uses the text table as an LRU cache. Oft-used programs are thus effectively sticky anyway. It is also worth noting that MACH always runs texts directly from the file system. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
treese@mit-trillian.MIT.EDU (Win Treese) (08/08/86)
In article <16@vianet.UUCP> devine@vianet (Bob Devine) writes: > > 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? > >Bob I don't think it's obsolete. In a workstation environment with the bulk of the software residing on a remote fileserver, keeping the text of some commonly used programs in memory speeds loading and cuts down on network traffic. We're using microVAXen and PC/RT's like this, and the sticky bit is very useful. Win Treese MIT Project Athena ARPA: treese@athena.MIT.EDU UUCP: ...!{decvax, genrad}!mit-eddie!mit-athena!treese
cprice@vianet.UUCP (Charlie Price) (08/09/86)
> 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
ross@ulowell.UUCP (Ross) (08/09/86)
In article <16@vianet.UUCP> devine@vianet (Bob Devine) writes: > > 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? Well I have found on a DG MV10000/SX, a machine that is supposed to be fast and occasionaly is, running DG/UX, that if the C compiler loader and other good stuff is installed sticky, it runs in about 1/4 the time if not installed sticky. Could be the immaturity of the OS though. Ross Miller csnet: ross%ulowell.csnet uucp: ..ulowell!ross Disklaimer: The above are my own opinions. I have formed them based on facts. DG and a lot of the rest of the article are trademarks of Data General.
grr@cbmvax.cbm.UUCP (George Robbins) (08/09/86)
In article <16@vianet.UUCP> devine@vianet (Bob Devine) writes: > > 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? > >Bob No, you still save (potentially) all kinds of overhead and disk I/O. Try the following I you aren't memory bound, and haven't done it already. Set the sticky bit on vi (or your favorite non-gnuemacs editor) - note improved repsonse time when you say vi fish. Next move your favorite terminal entry to the first n lines of /etc/termcap. voila! instant unix tuning...a win ~90% of the time. -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
guy@sun.uucp (Guy Harris) (08/09/86)
> 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? Yes. I interpret it as meaning conforming systems need not use this to mean "save text image after execution", if for example they don't have such a concept. If conforming systems can't use that bit to mean anything, no conforming systems exist; I sincerely doubt that AT&T-IS wants to be in the position that the OS of their machines doesn't conform to the SVID.... Applications written based on the specifications of the SVID should not use this bit, as its meaning is implementation-dependent. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
guy@sun.uucp (Guy Harris) (08/09/86)
> As to that I cannot say; but it is perhaps worth noting that 4.3 > now uses the text table as an LRU cache. Oft-used programs are > thus effectively sticky anyway. Heck, 4.*1*BSD used main memory as a cache for pages; when a text segment is released in 4BSD, its pages don't get tossed, they stick around in memory until the page daemon wants their page frames for something else (or until somebody writes to the block that the page belongs to). STICKY(8) in the 4.1BSD manual says under BUGS: Is largely unnecessary on the VAX; matters only for large programs that will page heavily to start, since text pages are normally caches incore as long as possible after all instances of a text image exit. I think "ex"/"vi" was the only program that has the sticky bit set in 4BSD. With enough main memory, even that won't buy you much, since the interesting pages of "ex"/"vi" would stick around. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
jrw@hropus.UUCP (Jim Webb) (08/11/86)
> I don't think it's obsolete. In a workstation environment with the bulk of > the software residing on a remote fileserver, keeping the text of some > commonly used programs in memory speeds loading and cuts down on network ^^^^^^ > traffic. The sticky bit does _not_ do this, I will assume you meant on the swap device... -- Jim Webb "Out of phase--get help" ihnp4!houxm!hropus!jrw
liam@cs.qmc.ac.uk (William Roberts) (08/11/86)
> is the sticky bit idea worthwhile?
We have 30 MG1 workstations on an Ethernet under NFS, each with
small (22 Meg) Winchesters. Each machine has a Unix kernel
with basic bootstrapping stuff and about 12 Meg of swap space
(We need that much for one of our language packages) so most
executables will have to be held on the fileservers.
These machines are allocated to undergraduate teaching, so they
will be used for very different things at different times,
typically in edit-compile-run sequences. To reduce traffic on
the Ethernet, we would like to "cache" executables on the local
machines and using that vast swap partition is very tempting;
is there any way to have a "fairly sticky" bit?
If we use the sticky bit as is, executables won't go away once
installed in the swap partition. What we need is some sort of
advisory sticky bit which keeps the executable on the swap
partition until someone else needs the space. A simple "least
recently used" freeing strategy would probably be adequate.
How hard would it be to do this, given that we don't need the
old-style sticky bit? Is it a good idea or have I really
flipped this time?
--
William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu)
Queen Mary College UUCP: liam@qmc-cs.UUCP
LONDON, UK Tel: 01-980 4811 ext 3900bobm@convexs.UUCP (08/11/86)
Devine@vianet writes: > 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? The relevant parameter is not the speed of the disks, but the relative speeds of swap I/O and filesystem I/O. Sticky programs are read from the swap volume instead of the file system. Sticky programs on VM systems are paged in from the swap volume. Program segments are stored contiguously on the swap volume. Since Berkeley unix has the Fast File System and VM, the sticky bit is obsolete for bsd systems. But the sticky bit is still useful in AT&T unix, because filesystem disk access time under AT&Tnix is dominated by seek time. K<bob> deep_thought() Bob Miller { Convex Computer Corporation sleep(years_to_seconds(7500000)); Richardson, Texas return 42; } {ihnp4,cbosgd,allegra,sun}!convex!bobm Disclaimer: The above is not just the opinion of the author; it is the opinion of all sentient beings in this universe and all other known universes. The author's employer may, however, not be sentient.
chris@umcp-cs.UUCP (Chris Torek) (08/16/86)
>Devine@vianet writes: >... is the sticky bit idea [still] worthwhile? In article <27300006@convexs> bobm@convexs.UUCP writes: >The relevant parameter is not the speed of the disks, but the relative >speeds of swap I/O and filesystem I/O. Change that to `relative average access time'; `speed' is not terribly well defined here. >Since Berkeley unix has the Fast File System and VM, the sticky bit is >obsolete for bsd systems. Not necessarily---not if the swap partition(s) have better access times than the regular file systems. I do suspect, however, that on most systems, the average access times are similar enough that paging texts from swap space is a waste of that same swap space. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu