Date: Tue, 1 Jun 2004 20:06:02 -0400 From: Bill Moran <wmoran@potentialtech.com> To: Charles Swiger <cswiger@mac.com> Cc: questions@freebsd.org Subject: Re: Whatever happened to the sticky bit (for files) Message-ID: <20040601200602.2a8f0aed.wmoran@potentialtech.com> In-Reply-To: <249F9CCA-B3F6-11D8-B50B-003065ABFD92@mac.com> References: <40BC8DC7.70603@potentialtech.com> <249F9CCA-B3F6-11D8-B50B-003065ABFD92@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Jun 2004 14:04:36 -0400 Charles Swiger <cswiger@mac.com> wrote: > 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. :-) Well ... I don't know how long it's been, I just remember seeing a reference somewhere to the historical meaning of the bit. > 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. That all depends on who you ask. There are small religions centered around the belief that compilers do not respect the "register" keyword like they really should ... but that's a different flame war ... ;) > 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. Absolutely, but what about monsters like OpenOffice? I'm also wondering if this is a Linux thing? I don't see my FreeBSD desktop machine giving me a lot of grief about programs I haven't used in a while being too slow to respond. I mean, there _is_ a problem sometimes, but the response is still usually better than a faster machine with more memory using Windows, so I figure FreeBSD has got a good set of VM algorithms going. (As a side note, a Fedora box running on the same hardware as the Windows box is between Windows and FreeBSD as far as responsiveness is concerned ... no _real_ data here, just my perception with regard to normal usage) -- Bill Moran Potential Technologies http://www.potentialtech.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040601200602.2a8f0aed.wmoran>