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>