From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri,  1 Jul 2011 13:23:03 -0400
To: henning@plan9.bell-labs.com, 9fans@9fans.net
Message-ID: <83656e84a9290648e03a7e880786e132@ladd.quanstro.net>
In-Reply-To: <20110701160026.0db036cd@leffe.cs.bell-labs.com>
References: <20110701160026.0db036cd@leffe.cs.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] why not halt in x86 multicore
Topicbox-Message-UUID: f8e0e93a-ead6-11e9-9d60-3106f5b1d025

On Fri Jul  1 13:06:36 EDT 2011, henning@plan9.bell-labs.com 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