Date: Fri, 13 Aug 1999 15:54:20 -0700 From: Mika Nystrom <mika@cs.caltech.edu> To: Peter Wemm <peter@netplex.com.au> Cc: alc@cs.rice.edu, blanquer@cs.ucsb.edu, freebsd-smp@FreeBSD.ORG, BMCGROARTY@high-voltage.com, tech-kern@netbsd.org Subject: Re: Questions Message-ID: <199908132254.PAA02257@gauguin.cs.caltech.edu> In-Reply-To: Your message of "Sat, 14 Aug 1999 05:51:17 %2B0800." <19990813215117.717011C1E@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm writes:
...
>
> to top priority due to starvation, then it could well run at higher
> priority than a the three normal processes if it had the whole cpu to itself
>.
>
>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.
>
>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
>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.
>
...
Hello,
We have a user here who insists on running rc5des on a lab full of
NetBSD/i386 machines (all UP, of course). I made a simple hack to
the scheduler to solve this problem. The scheduler on our machines
simply reserves the bottom-most run queue for nice 20 processes.
I PR'd it for NetBSD, but it's such a crude hack that I'm not surprised
it hasn't gotten any attention. Well, it's crude, but it really does
do the trick as far as these rc5 clients are concerned. You simply
cannot tell that one is running in the background.
I was going to apply the patch to FreeBSD but FreeBSD has code that does
exactly the same thing using the rtprio mechanism.. I would guess that
using idprio on the FreeBSD des clients would work the same as my NetBSD
hack. Of course, processor affinity, etc. is a much bigger question
that this two-liner does nothing to address.
Mika
void
resetpriority(p)
register struct proc *p;
{
register unsigned int newpriority;
newpriority = PUSER + p->p_estcpu / 4 + 2 * (p->p_nice - NZERO);
#ifdef HARDNICE
newpriority = min(newpriority, MAXPRI-PPQ-1);
if (p->p_nice == (PRIO_MAX + NZERO) ) newpriority = MAXPRI;
#else
newpriority = min(newpriority, MAXPRI);
#endif
p->p_usrpri = newpriority;
if (newpriority < curpriority)
need_resched();
}
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?199908132254.PAA02257>