On Jun 1, 2004, at 10:08 AM, Bill Moran wrote:
Unless I'm mistaken, at one time turning on the sticky bit on a binary would
tell the kernel not to swap out that program when it was running (or
somtehing similar ... I think it used to mean "kernel must never swap out
this data")

That's right, although it's been a few years since that has been used by any OS I can point to. :-)


The general idea was that if the system is under VM pressure, it would end up swapping out pages of memory from inactive processes, only you don't want to swap out parts of /bin/sh, or cron, or some other long-running daemons, because you'll end up wanting those pages resident again soon. So you'd mark certain important executables with the sticky bit to help the VM system focus on evicting less critical pages.

Anyway ... considering the arguments that swap algorithms can be stupid
(they have to balance the need for disk cache with the need for app space)
Wouldn't it make sense to put some of that power back in the hands of the
admins and developers?

Maybe. The situation may more closely resemble the case of using the "register" keyword in C code. At one point, that helped the compilers focus on optimizing the right variables, and also had the advantage of preventing usage of those variables from being potential memory aliases to other parts of memory.


Nowadays, the compilers do a good enough job of optimizing register usage for themselves that the "register" keyword is somewhere between not very useful and counterproductive.

VM paging algorithms have improved since the usage of the sticky bit was common, and available physical memory on typical systems has also increased significantly. VM systems which use a global page-fault frequency algorithm to help balance memory usage between processes tend to give /bin/sh and other essential daemons enough RAM that you don't tend to swap out their pages anyway when the VM system is looking for pages to evict.

--
-Chuck

_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to