From owner-freebsd-hackers Fri Jan 22 04:38:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA10749 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 04:38:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA10744 for ; Fri, 22 Jan 1999 04:38:58 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id EAA27145; Fri, 22 Jan 1999 04:34:50 -0800 (PST) Message-Id: <199901221234.EAA27145@implode.root.com> To: Matthew Dillon cc: "John S. Dyson" , hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change In-reply-to: Your message of "Fri, 22 Jan 1999 03:46:13 PST." <199901221146.DAA52510@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 22 Jan 1999 04:34:50 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A scheduler is not an artificial block/sleep mechanism such as the > piece of code I ripped out -- it is scheduling available free memory > to processes needing memory based on their memory-hogging priority. > So, for example, a process that has been freeing memory recently is > given a very high allocation priority whereas a process that has been > allocating a lot of memory is given a lower allocation priority. The > priority of the requester is run through the scheduler -- say a > fractional/fair scheduler, which decides how to dole out the available > free memory. Processes only block when memory is exhausted, and then > only based on their scheduling priority. The root ssh login and shell > still works, as do the processes that tend to be memory-neutral. A > fractional/fair scheduler usually has a very smooth degredation curve, > too. What John is saying is that such a policy will usually not provide the best overall system performance - in fact it can be a major pessimization. Both John and I have done literally years of experimentation with various algorithms, testing overall performance as well as effect on interactive response times and what was in FreeBSD was a pretty good balance between these two. That's not to say that it was the "best" balance or that it can't be significantly improved, but some of the things you're proposing are really quite counter to the experiance we've gained in this area. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message