Date: Sun, 26 Jan 2003 01:25:11 -0600 From: "Michael C. Wu" <keichii@iteration.net> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Steve Kargl <sgk@troutmask.apl.washington.edu>, Jeff Roberson <jroberson@chesapeake.net>, Gary Jennejohn <garyj@jennejohn.org>, arch@FreeBSD.ORG Subject: Re: New scheduler Message-ID: <20030126072511.GB97105@endless.iteration.net> In-Reply-To: <Pine.NEB.3.96L.1030125135459.3121B-100000@fledge.watson.org> References: <20030125045205.GA15091@troutmask.apl.washington.edu> <Pine.NEB.3.96L.1030125135459.3121B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 25, 2003 at 01:58:33PM -0500, Robert Watson scribbled:
| > > It did not help. The load averages reported be top(1)
| > > with the above change in palce are 7.86, 9.01, 8.72.
Perhaps a better benchmark would be running simulataneous processes
and timing them with a physical stopwatch.
| > Jeff, it isn't the painkillers. The 2nd sentence should read "The load
| > averages, reported by top(1) with the above change in place, are 7.86,
| > 9.01, 8.72"
|
| Part of the problem is that the load average is a poor measure of system
| utilization. Jeff's new scheduler may defer scheduling a process that's
| ready to run to improve throughput and wait for a "better" CPU to run a
| process on based on affinity. Potentially the result might be that the
| run queues are (on average) deeper, and what the load average does is
| measure the depth of the run queue over time. So for the moment, it's
| probably best to disregard load average as a measure of performance. On
| the other hand, actual interactivity regressions and performance changes
| are very relevant. Load average is intended to capture the degree of
| contention for CPU resources, but what exactly that means is always an
| interesting question.
After looking at the code somewhat (did not have enough time to read into
the details), here are my humble suggestions.
1. Processor affinity is a two-edged sword, and optimizing a MP scheduler
for a UP machine is almost a lost cause. Perhaps you can consider
treating UP as a special case and look at the MP case without holding back.
2. Keep in mind that the Athlon MP you are using has a medium sized
cache compared to large ones in Xeons and Alphas, and the P4 has
trace caches built-in. Assuming that you have plans for future SMT
architectures like p4-hyperthreads, your optimizations may fail.
My suggestion is that you create a scoring matrix of sorts and dynamically
test out run queue depth and affinity scores. (From experience,
linear systems work the best.) After a period of time, a system will have
"learned" to deal with the job that it is supposed to.
Intel designed the P4 caches to be small so we can trash them, so to say.
3. In the scoring matrix, you may wish to give prioritizing affinity
for certain processes like controlling the ata bus, mouse movements etc.
Since you are creating a general purpose structure, remember that
a lot of us use FreeBSD for scientific computing, with little disk I/O
and lots of memory/cpu usage. Others like Yahoo! webfarms will want
preference for disk I/O and network interface controlling priorities.
If you are interested in the dynamic testing system, we can discuss this
on IRC or in the follow-up emails.
Regards,
Michael
--
Michael C. Wu keichii@{ iteration.net | FreeBSD.org | ece.utexas.edu |
iis.sinica.edu.tw | ntugene.ibs.ntu.edu.tw }
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030126072511.GB97105>