Date: Fri, 13 Aug 1999 17:27 -0600 From: "Brian McGroarty" <BMCGROARTY@high-voltage.com> To: "Peter Wemm" <peter@netplex.com.au> Cc: "Alan Cox" <alc@cs.rice.edu>, "Josep Maria M. Blanquer" <blanquer@cs.ucsb.edu>, "freebsd-smp" <freebsd-smp@FreeBSD.ORG> Subject: RE: Re: Questions Message-ID: <B7595390B950D31186D50008C7333C82@high-voltage.com>
next in thread | raw e-mail | index | archive | help
From: Peter Wemm [mailto:peter@netplex.com.au] > > This lack of granularity really sucks and hurts a lot when > running things like > rc5des etc in the background, even on a single cpu system. It's very > spectacular when you have a graphical program running. For > one second, it > runs at full speed. The next second, it runs at half speed > as it's sharing > the top run queue with rc5des. Then, it's back to full speed > again, and so > on every second. Yeah, I stopped running rc5des for this reason. The imbalance exists in the single processor model when one process is in a queue above or below a pool of other processes, yes. But your model seems like it has the potential to take a nice 19 process, develop complete affinity on one processor with everything else in a pool below, and then even if it falls into the same pool as the others, they've developed affinity for the other processor. The result? Zoom! nice 19 is shot downward and out of the crowd in the next scheduling interval like the proverbial watermellon seed. Without this affinity model, the process wouldn't likely dip below the pooled process queue and it would level off its processor usage before timidly starting to climb again. I expect your test model approaches a near perfect model as you tighten the scheduling quantum to a 1:1 schedcpu():roundrobin() interval if we ignore the schedcpu(). Hard to do with all that resultant locking, but that's changing, I guess. Just as a thought exercise, I wonder how optimal an incrementally changing schedcpu() could be, as opposed to the current block reorganization. > I made a few tweaks here a while ago to enable speeding up > the scheduler > that fixed this, but bde said he had other patches to fix it > properly. I > ended up frying my patch set somehow and never got back to > it. When bde Oi, that's NOT what I wanted to hear. I'd much rather learn about this in C than Intel assembly. > committed his changes, it made little difference here. I > think it now takes > 1/4 of a second for the lower priority process to loose the > top priority now. > I think the SMP "BETTER_CLOCK" stuff does similar things. I'll look at BETTER_CLOCK. I like Terry's model though - I'm going to do some reading and see if I can find something similar for reference. Do you know of, or have you considered, any other processor affinity scheduling models? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B7595390B950D31186D50008C7333C82>