Whatever happened to the sticky bit (for files)

[Bill Moran]

This may be better suited for hackers@, but I thought I'd bring it up here
to get perspective.

I was reading this article: http://kerneltrap.org/node/view/3202 and related
articles that it links to, and thinking - why did the sticky bit go away?

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")

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?

If the sticky bit meant something again ... then admins would have control!

Imagine this.  The kernel has a new sysctl: use_sticky or something, that
allows an admin to revert back to current behaviour.  The kernel then takes
the sticky bit on an executable file to mean, "do not swap this out unless
there's nowhere else to get memory from".  This would give the admin the
ability to pick certain apps that must always respond quickly (even after
long periods without use) and force them to stay in physical RAM where
they could jump right to the task.  Setting kern.use_sticky=0 causes the
kernel to ignore the sticky bit and treat all programs the same, in case
this causes problems for someone.

Now, what complexity this might introduce into the kernel is beyond my
complete understanding, and that complexity alone might prevent such a
change.

But I'm interested as to why it hasn't been done.  I simply refuse to
think that nobody else has thought of it.  I just figure that there's
a good reason somewhere why not to do it.

-- 
Bill Moran
Potential Technologies
http://www.potentialtech.com