9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Ali Mashtizadeh <mashtizadeh@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] why not halt in x86 multicore
Date: Fri,  1 Jul 2011 10:47:56 -0700	[thread overview]
Message-ID: <BANLkTikaVKx85WXzeZkiBWaOWXW1hCmX9Q@mail.gmail.com> (raw)
In-Reply-To: <83656e84a9290648e03a7e880786e132@ladd.quanstro.net>

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 <quanstro@quanstro.net> wrote:
> 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
>
>



  reply	other threads:[~2011-07-01 17:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-01 14:00 Henning Schild
2011-07-01 17:23 ` erik quanstrom
2011-07-01 17:47   ` Ali Mashtizadeh [this message]
2011-07-01 17:51     ` Russ Cox
2011-07-01 18:01       ` erik quanstrom
2011-07-01 18:35         ` Bakul Shah
2011-07-02  5:06           ` Venkatesh Srinivas
2011-07-04  9:24   ` Henning Schild
2011-07-04  9:54     ` Sape Mullender
2011-07-04 13:02     ` erik quanstrom
2011-07-04 13:13       ` Steve Simon
2011-07-04 13:43         ` erik quanstrom
2011-07-04 13:47         ` Steve Simon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTikaVKx85WXzeZkiBWaOWXW1hCmX9Q@mail.gmail.com \
    --to=mashtizadeh@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).