sticky bit

[T. William Wells]

In article <8739 at alice.UUCP> debra at alice.UUCP () writes:
: In article <325 at twwells.uucp> bill at twwells.UUCP (T. William Wells) writes:
: }Program development on my system. It is a 16MHz 386, 4M RAM, 80M 28ms
: }seek time disk.  I run Microport's SV/386 3.0e (the latest).  Load
: }time on my editor, for example, is cut from about three seconds on
: }initial startup, to under a second. Compile times are cut similarly.
: }(Most of the compile time seems to be related to loading the compiler
: }passes!)
:
: I believe I recently read a message saying that Microport actually keeps
: sticky-bit programs IN MEMORY, instead of swapping them out to disk.

You did. I said it. It comes from the man page for chmod(2).  It says
413 executables stay in memory after all processes have stopped using
them.  413's are paged straight from the a.out file.

: This could easily explain your performance gain. Try running a huge
: application, and edit and compile after that. (the huge application will
: absorbe the memory so the sticky-bit applications have to be moved to the
: swap-space again. I would be surprised if you would still have this 300%
: improvement.

You are right.

: }I have no problem with unmounting my /usr file system, even though I
: }have a sticky-bit program (my editor) on it. Overwriting, on the
: }other hand, still requires deleting the file first.
:
: There is no reason why a system should be unable to figure out what to
: do when you unmount a file system. Apparently SV/386 has figured it out.

At least for removing the stuff when unmounting. It ought to be able
to let you overwrite the program as well. Oh well, maybe next version.

---
Bill
{ uunet!proxftl | novavax } !twwells!bill