From owner-freebsd-smp Fri Aug 13 13:30: 6 1999 Delivered-To: freebsd-smp@freebsd.org Received: from high-voltage.com (voltage.high-voltage.com [205.243.158.175]) by hub.freebsd.org (Postfix) with SMTP id BCA1214C0F for ; Fri, 13 Aug 1999 13:29:56 -0700 (PDT) (envelope-from BMCGROARTY@high-voltage.com) Date: Fri, 13 Aug 1999 15:11 -0600 From: "Brian McGroarty" To: "Peter Wemm" , "Alan Cox" Cc: "Josep Maria M. Blanquer" , "freebsd-smp" Subject: RE: Re: Questions Message-ID: <6E585390B950D31186D50008C7333C82@high-voltage.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does this selection mode skew overall processor allocation measurably? I imagine allocation is severely skewed by roundrobin() between schedcpu() calls, but then the high p_estcpu bumps the favored task down a run level queue, compensating with a moment of being starved a processor. The worst case would then be a high priority task with a goodly sized pool of others a few run queue levels down. The process would race and then bob down, float up as p_estcpu is averaged down through schedcpu() calls, soon climb a layer back up for its higher priority, then race and pitch downward again. -----Original Message----- From: Peter Wemm [mailto:peter@netplex.com.au] Sent: Friday, August 13, 1999 4:55 AM To: Brian McGroarty; Alan Cox Cc: Josep Maria M. Blanquer; freebsd-smp Subject: Re: Questions > Try asking John Dyson (dyson@iquest.net). I think he has > experimented with some limited forms of affinity scheduling. I've done this BTW and have it currently running. I've turned up a bug or two that look awfully like something is changing p->p_priority of processes while they are on run queues. Even doing trivial affinity makes a big difference here. Trivial meaning that when selecting a process to run, walk the current run queue level and find the first process with a matching lastcpu id rather than just the first in the queue. If no match, then take the head. This is what John did, but I rewrote setrunqueue, remrq in C and moved the process selection out of i386/swtch.s and into C. The compiler generates suprisingly similar code to the assembler version, but when you turn on the U/V pipeline scheduling and the cpu-specific code generation options (eg: use cmove etc) then it seems to do slightly better than the original assembler code. This dramatically simplifies the complexity of cpu_switch() and swtch.s and moves the run queue management to MI code. All that is left in cpu_switch() is the actual context switch code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message