Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jan 1999 16:09:58 -0500 (EST)
From:      "John S. Dyson" <dyson@iquest.net>
To:        dillon@apollo.backplane.com (Matthew Dillon)
Cc:        dhw@whistle.com, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Error in vm_fault change
Message-ID:  <199901262109.QAA01076@y.dyson.net>
In-Reply-To: <199901262044.MAA21318@apollo.backplane.com> from Matthew Dillon at "Jan 26, 99 12:44:27 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon said:
> 
>     I did a huge amount of playing around with FreeBSD's scheduler back
>     in the 'early days' of BEST ( we were actually running FreeBSD for a bit
>     before we made the SGI blunder ).  In those days, our two shell machines 
>     were running at a constant load of 15 or more.
> 
>     I tried all sorts of stuff, but none of it performed significantly better
>     then the existing scheduler.  And, as cpu speeds started to increase, 
>     it became less and less of an issue.
> 
Back in the very early days of FreeBSD (around 1.1), I noticed that
interactive performance was poor (relative to SVR3.)  When reviewing
the scheduler code (actually the fork code), I saw that on a session
basis, a user could "boost" their priority by performing fork operations.
Those fork operations forgot previous CPU usage.

In order to provide smooth performance, I added a cpu scheduler stats
accumulation for the parent process so that the "session" would appear
to have consistant cpu usage, and therefor consistant running priority.
For most if it's life, FreeBSD has had this change, and does demonstrate
that small changes in the scheduler behavior can have a significant effect
on perceived performance.

Now, a parent process accumulates the effects of it's children (upon
their exit) so that there is no apparent priority boost, and more
smooth interative behavior.

Note that SVR4 with it's new scheduler (at the time) has the same problem
that FreeBSD originally did.  On retrospect, I reviewed SVR3 and found that
it had a similar mechanism that I added to FreeBSD for recent cpu usage
reverse inheritance from children to parent.

Recently, NetBSD broke that reverse inheritance (that they either borrowed
from FreeBSD, or developed independently), and there were cries about the
terrible interactive performance!!!  Of course, they fixed it ASAP...

-- 
John                  | Never try to teach a pig to sing,
dyson@iquest.net      | it makes one look stupid
jdyson@nc.com         | and it irritates the pig.

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?199901262109.QAA01076>