Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Jun 2004 14:04:36 -0400
From:      Charles Swiger <cswiger@mac.com>
To:        Bill Moran <wmoran@potentialtech.com>
Cc:        questions@freebsd.org
Subject:   Re: Whatever happened to the sticky bit (for files)
Message-ID:  <249F9CCA-B3F6-11D8-B50B-003065ABFD92@mac.com>
In-Reply-To: <40BC8DC7.70603@potentialtech.com>
References:  <40BC8DC7.70603@potentialtech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?249F9CCA-B3F6-11D8-B50B-003065ABFD92>