The hlt instruction on x86 leaves the halt state after an external interrupt is fired. I'm not sure why you think it doesn't work? If you need to wake up other cores then you may need IPIs is that what you mean?
~ Ali On Fri, Jul 1, 2011 at 10:23 AM, erik quanstrom <[email protected]> wrote: > On Fri Jul 1 13:06:36 EDT 2011, [email protected] wrote: >> in pc/main.c idlehands() the kernel decides to release the CPU only >> when you are not running a multicore kernel. As a result there is only >> busy waiting. Unfortunately there is no hint telling why we do not let >> the CPU rest a little. >> >> > void >> > idlehands(void) >> > { >> > if(conf.nmach == 1) >> > halt(); >> > } >> >> I am running a mostly idle plan9 VM on my laptop and it causes the >> battery to discharge in no time. Right now my kernel has the condition >> commented out and it seems to work fine. Still i would like >> to understand why this condition was put there. It is probably causing a >> lot of energy to be wasted which should better be for a good reason. > > right! this is an interesting problem. > > suppose that i have a multicore machine and all maches > have executed halt(). then, if i get an interrupt on one that > causes a proc to be ready, then i have to wait until the next > clock tick to sched() it on any other core. this is going to be a > huge performance hit, especially if you are using a 100hz clock > as the distribution does. for me a potential latency on the order > of 1-10ms is not going to cut it. > > there are a number of potential solutions to this that i'd like to > try, but i haven't had any time yet. > > - erik > >
