From owner-freebsd-questions@FreeBSD.ORG Tue Jun 1 07:08:13 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67C6C16A4CE for ; Tue, 1 Jun 2004 07:08:13 -0700 (PDT) Received: from internet.potentialtech.com (h-66-167-251-6.phlapafg.covad.net [66.167.251.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3886443D48 for ; Tue, 1 Jun 2004 07:08:13 -0700 (PDT) (envelope-from wmoran@potentialtech.com) Received: from potentialtech.com (pa-plum1c-102.pit.adelphia.net [24.53.179.102]) by internet.potentialtech.com (Postfix) with ESMTP id 16C9969A71 for ; Tue, 1 Jun 2004 10:08:11 -0400 (EDT) Message-ID: <40BC8DC7.70603@potentialtech.com> Date: Tue, 01 Jun 2004 10:08:07 -0400 From: Bill Moran User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040506 X-Accept-Language: en-us, en MIME-Version: 1.0 To: questions@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Whatever happened to the sticky bit (for files) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 14:08:13 -0000 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