Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jan 1999 04:34:50 -0800
From:      David Greenman <dg@root.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        "John S. Dyson" <dyson@iquest.net>, hackers@FreeBSD.ORG
Subject:   Re: Error in vm_fault change 
Message-ID:  <199901221234.EAA27145@implode.root.com>
In-Reply-To: Your message of "Fri, 22 Jan 1999 03:46:13 PST." <199901221146.DAA52510@apollo.backplane.com> 

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901221234.EAA27145>