Date: Fri, 31 Dec 1999 00:17:35 +0800 From: Peter Wemm <peter@netplex.com.au> To: Wilko Bulte <wilko@yedi.iaf.nl> Cc: Rasmus Kaj <kaj@ns.Raditex.se>, tsikora@powerusersbbs.com, "freebsd-stable@FreeBSD.ORG" <freebsd-stable@FreeBSD.ORG> Subject: Re: Temperature Message-ID: <19991230161735.921061CC6@overcee.netplex.com.au> In-Reply-To: Message from Wilko Bulte <wilko@yedi.iaf.nl> of "Thu, 30 Dec 1999 14:15:01 %2B0100." <19991230141501.C62691@yedi.iaf.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Wilko Bulte wrote:
> On Thu, Dec 30, 1999 at 08:07:11PM +0800, Peter Wemm wrote:
> > Rasmus Kaj wrote:
> > > Peter Wemm wrote, about processor temp, etc:
> > >
> > > > The main difference is that Linux halts the cpu in the idle loop, we do
n't.
> > > > As a result the cpu is in a tight spin waiting for a process to become
> > > > scheduleable. I have some patches half-done that I've been working on
for
> > > > 4.0 that should probably be able to be adapted to the 3.x series.
> > >
> > > The FAQ says that FreeBSD does use the HLT instruction when idle, is
> > > this wrong?
> >
> > In uniprocessor mode, yes it uses HLT (and always has). Under SMP it does
> > not (and never has).
>
> Peter,
>
> please allow me a layman's question: is there an easy explanation for this
> difference?
Yes.
Under UP, the cpu only goes to sleep if there is absolutely nothing else to do
except wait for an interrupt (clock, etc).
Under SMP, there is more than one cpu. If one cpu is asleep in a HLT, and
the other one changes the run queues, there is nothing to wake up the
sleeping CPU even though there is now a job in the queue. So.. we let the
cpu spin looking at the "queue not empty" bits so it never gets caught sleeping
on the job.
Now we have a more flexible IPI system and have moved the runqueue manipulation
out of assembler (in -current only) into specially tuned C code, we can easily
add an IPI transmission call to the "add process to a run queue" routine. This
isn't automatically a good idea though.. sending an IPI is relatively expensive
so we don't want to do it unless it's needed.
Defining "when needed" is the tricky part. Remember that the cpu doing the
change to the run queue is holding the kernel lock, so the other cpu cannot
enter the kernel to get a process while the first one is holding the lock.
We also don't want to wake the other cpu if there is only one single process
in the queues as the current cpu will take it and by the time the other cpu
gets into the kernel at last, the queues will be empty again and we'll have
wasted an IPI.
Probably the best thing to do is have each cpu set a bit flag indicating
it's halting, and each time a cpu is leaving the kernel to return to user
mode it should check if there is still another process available and at
least one cpu is sleeping, then do a targeted IPI to wake up the sleepers.
The initial cpu will leave the kernel lock in a moment and one of the other
cpus will grab the process.
As I've said, I've half finished this (under -current), it shouldn't be too
hard to finish the rest.
On the subject of CPU heat etc, remember that halting a cpu doesn't do a
thing if you're running seti@home or rc5des or something cpu intensive.
There is always something to run and the halt never happens.
One would assume that people with SMP machines actually intend to use the
CPUs so that's the other reason it's never bothered anyone enough to finish
it.
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991230161735.921061CC6>