Date: Sat, 25 Jan 2003 11:25:21 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Jeff Roberson <jroberson@chesapeake.net>, Gary Jennejohn <garyj@jennejohn.org>, arch@FreeBSD.ORG Subject: Re: New scheduler Message-ID: <20030125192521.GA18048@troutmask.apl.washington.edu> 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 wrote: > On Fri, 24 Jan 2003, Steve Kargl wrote: > > On Fri, Jan 24, 2003 at 08:47:41PM -0800, Steve Kargl wrote: > > > > > > It did not help. The load averages reported be top(1) > > > with the above change in palce are 7.86, 9.01, 8.72. > > > > 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. > Robert, I'm sure your analysis is correct. All I can say is that Jeff's experimental scheduler will bring a UP system to its knees. The system I tested on runs NTP to sync the clock, and the system clock lost 6 minutes of wall-clock time in 45 minutes. The two possible causes of the problem (that I can think of) are (1) deadlock in the scheduler or (2) processes are ping-ponging between run queues without actually getting a time slice. Unfortunately, I was running X window at the time and could not break into the debugger. I'll try again later today to what ddb says. -- Steve 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?20030125192521.GA18048>