sticky bit

[Paul De Bra]

In article <325 at twwells.uucp> bill at twwells.UUCP (T. William Wells) writes:
}In article <8724 at alice.UUCP> debra at alice.UUCP () writes:
}: In article <314 at twwells.uucp> bill at 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.
}
}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.
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.

}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.

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