"oread::barbanis"@coins.cs.umass.edu (04/23/88)
Greetings. Is there any reason at all to have the sticky bit on in an executable? Or, to put it differently, under what circumstances should it be set? (circumstances such as program size, hardware/OS, program usage pattern, etc.) Unless I've missed something, only the ex/vi family editors have the sticky bit on, on both our Suns and Vaxen. Why is this A Good Thing (or is it A Good Thing at all?) George Barbanis barbanis@cs.umass.edu
sarima@gryphon.CTS.COM (Stan Friesen) (04/25/88)
In article <13085@brl-adm.ARPA> "oread::barbanis"@coins.cs.umass.edu writes: > >Is there any reason at all to have the sticky bit on in an executable? >Or, to put it differently, under what circumstances should it be set? >(circumstances such as program size, hardware/OS, program usage >pattern, etc.) >Unless I've missed something, only the ex/vi family editors have >the sticky bit on, on both our Suns and Vaxen. Why is this A Good Thing >(or is it A Good Thing at all?) > The sticky bit should be set *only* for very heavily used programs that are not in continuous use. It is intended to help reduce the startup overhead of major system utilities, like vi, especially moderately large ones. WARNING: setting the sticky bit uses up swap space and RAM, so make sure you have enough of both to handle ALL sticky programs plus any normal user program mix that you can foresee. Thus on most systems only vi/ex and perhaps the shells need or should have the sticky bit set. On some turnkey systems it might be useful to make the main user application sticky as well. -- Sarima Carandolandion sarima@gryphon.CTS.COM aka Stanley Friesen rutgers!marque!gryphon!sarima Sherman Oaks, CA
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (04/26/88)
In article <3571@gryphon.CTS.COM# sarima@gryphon.CTS.COM (Stan Friesen) writes: #In article <13085@brl-adm.ARPA# "oread::barbanis"@coins.cs.umass.edu writes: ## ##Is there any reason at all to have the sticky bit on in an executable? ##Or, to put it differently, under what circumstances should it be set? ##(circumstances such as program size, hardware/OS, program usage ##pattern, etc.) # ...... # The sticky bit should be set *only* for very heavily used programs #that are not in continuous use. It is intended to help reduce the startup #overhead of major system utilities, like vi, especially moderately large ones. #WARNING: setting the sticky bit uses up swap space and RAM, so make sure you #have enough of both to handle ALL sticky programs plus any normal user program #mix that you can foresee. Thus on most systems only vi/ex and perhaps the #shells need or should have the sticky bit set. On some turnkey systems it #might be useful to make the main user application sticky as well. The sticky bit is ONLY meaningful for swapping machines. On demand paging it doesn't make much sense. It was used because the "text" for a program was scattered on the disk (as a file). It was fully loaded into core (no partial loads on swapping). The text would then (we hope) be copied onto the swap disk as one contiguous image. Hence loading it from swap was much faster (if the disk driver and hardware allowed a single transfer). With demand paging the disk file is page aligned and the pages are swapped in from the file system as required and not placed on the swap/page device unless modified. Hence the sticky bit isn't of much use. Also VERY heavy programs such as shells never need the sticky bit. Consider the shell. It is always in use. Hence its text is around. -- =Dennis L. Mumaugh Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm
friedl@vsi.UUCP (Stephen J. Friedl) (04/26/88)
In article <3571@gryphon.CTS.COM>, sarima@gryphon.CTS.COM (Stan Friesen) writes: > In article <13085@brl-adm.ARPA> "oread::barbanis"@coins.cs.umass.edu writes: > >["When do I use the sticky bit?"] > The sticky bit should be set *only* for very heavily used programs > that are not in continuous use. [...] Thus on most systems only vi/ex and > perhaps the shells need or should have the sticky bit set. I don't believe that setting the sticky bit on the shell buys anything. Once you login, its image stays around because it is in use -- I believe the sticky bit only affects treatment of images not being used. This is reflected by the "only by programs not in continuous use" statement; the shell is not likely to be one of these programs. -- Steve Friedl V-Systems, Inc. spaf@purdue for President! friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
vrs@littlei.UUCP (vrs) (04/26/88)
Since when is the shell in continuous use? You guys DO log out when you go home, don't you?? You guys DO go home, don't you?? Hey, it's 2AM, (and I'm at home) and from 2-8AM, I expect the shell to come and go like any other program. When I log in in the morning, things will be speedy because AT&T has elected to waste swap space (yes, we demand page but swap too) keeping stuff around for the shell's text region. I agree that the sticky bit on the shell is not a big win, but wanted to point out that that last copy DOES exit several times a day.
dwc@homxc.UUCP (Malaclypse the Elder) (04/26/88)
In article <1768@cuuxb.ATT.COM>, dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) writes: > # The sticky bit should be set *only* for very heavily used programs > #that are not in continuous use. It is intended to help reduce the startup > #overhead of major system utilities, like vi, especially moderately large ones. > #WARNING: setting the sticky bit uses up swap space and RAM, so make sure you > #have enough of both to handle ALL sticky programs plus any normal user program > #mix that you can foresee. Thus on most systems only vi/ex and perhaps the > #shells need or should have the sticky bit set. On some turnkey systems it > #might be useful to make the main user application sticky as well. behrohk samadi has developed an expert system for unix administration called TUNEX. one of the things it does is look at process accounting data to determine which programs are candidates for sticky bitting. she presented TUNEX at the 1987 winter usenix in washington and a paper is in the conference proceedings. it is available as part of the at&t toolchest. > > The sticky bit is ONLY meaningful for swapping machines. On > demand paging it doesn't make much sense. It was used because the > "text" for a program was scattered on the disk (as a file). It > was fully loaded into core (no partial loads on swapping). The > text would then (we hope) be copied onto the swap disk as one > contiguous image. Hence loading it from swap was much faster (if > the disk driver and hardware allowed a single transfer). > > With demand paging the disk file is page aligned and the pages > are swapped in from the file system as required and not placed on > the swap/page device unless modified. Hence the sticky bit isn't > of much use. > while these comments are generally true for current paging versions of System V on 3B2s, the value of sticky bits are implementation dependent. one way to look at it is that the swap area is a contiguous "filesystem" for kernel use. so if there is a difference between the performance of doing I/O from the swap area and the standard unix filesystem, then the sticky bit is available to use as a means of specifying which programs might benefit from some overhead to save on I/O (hint hint). on current paging versions on the 3B2, for example, the filesystem block size is typically 1K while the page size is 2K. thus if a program were sticky bitted and stayed on the swap device even though not contiguous, it would still benefit from having to do 1 I/O from the swap device per page fault instead of 2 I/Os from the filesystem. unfortunately, i'm not sure whether the recent releases still have a quirk in them such that this only works for sticky bitted programs with magic number 410 (default is 413). danny chen homxc!dwc
denny@mcmi.UUCP (Dennis Page) (04/27/88)
In article <1768@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >The sticky bit is ONLY meaningful for swapping machines. On >demand paging it doesn't make much sense. This is incorrect. In USG V3 the sticky bit will cause text pages to remain in memory even when the command is not being used (unless the free pages drops below the low water mark). This can be a major win if used correctly. It sure helps the startup time of emacs. :-) -- Denny Page "So many pedestrians, so little time." Martha, the Clones are loose again!
erskine@force10.UUCP (Neil Erskine) (04/28/88)
In article <3571@gryphon.CTS.COM> sarima@gryphon.CTS.COM (Stan Friesen) writes: >In article <13085@brl-adm.ARPA> "oread::barbanis"@coins.cs.umass.edu writes: >> >>Is there any reason at all to have the sticky bit on in an executable? >>Or, to put it differently, under what circumstances should it be set? > The sticky bit should be set *only* for very heavily used programs >that are not in continuous use. It is intended to help reduce the startup >overhead of major system utilities, like vi, especially moderately large ones. ..... >Thus on most systems only vi/ex and perhaps the >shells need or should have the sticky bit set. On some turnkey systems it >might be useful to make the main user application sticky as well. On the systems I have used (System V variants, swapping and paging), setting the sticky bit on a shell is of little or no use. The effect of the sticky bit is the same as the effect of someone already executing the program. In the case of the shell, this is practically always so. If you have a system with a large number of users, most of whom use the editor at length, making the editor sticky is similarly ineffective, as the system almost always finds the program running elsewhere. For single user systems it is of course quite valuable. I have found the sticky bit useful on programs that are often used, but for short periods of time, such as test and expr, compiler passes, and programs of that nature. On the whole, the sticky bit is unnecessary. I doubt that it has any significant effect on paging systems at all, which may in fact ignore it. A question that intrigues me, however, is why in Xenix-386 (a paging system) the disk is always physically accessed when a process is started? Accounting in this case is turned off. When I run a program while the system has lots of free memory, a small program, and given the same data set as used by another currently executing invocation of the program, I would have thought that everything that has to be read would be in the buffer cache, or in a memory resident text segment. But the disk light always flashes. Why? Neil Erskine -- Neil S. Erskine MT&T - (902) 453-4915 x340 AP Computers USENET { garfield, watmath, ihnp4!utzoo!utai, 3845 Dutch Village Rd. uunet } !dalcs!force10!erskine Halifax, N.S. B3L-4H9
rbj@icst-cmr.arpa (Root Boy Jim) (04/29/88)
From: vrs <vrs@littlei.uucp> Since when is the shell in continuous use? You guys DO log out when you go home, don't you?? You guys DO go home, don't you?? No, I run lock. My .cshrc/.login startup time rivals that of emacs, which I never exit either, unless I screw up my environment. I just ^Z it. Oh, and don't tell me about the 15 minute lock timeout. I use the 4.2 one. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement .. the HIGHWAY is made out of LIME JELLO and my HONDA is a barbequeued OYSTER! Yum!