9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Sape Mullender <sape@plan9.bell-labs.com>
To: 9fans@9fans.net
Subject: Re: [9fans] why not halt in x86 multicore
Date: Mon,  4 Jul 2011 11:54:17 +0200	[thread overview]
Message-ID: <c1c3d594d290ec864d92dd5e971cd86e@plan9.cs.bell-labs.com> (raw)
In-Reply-To: <20110704112420.16237b22@leffe.cs.bell-labs.com>

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

Indeed, there's an assumption that each core manages the TLB by
examining the data structures at clock frequency.  In a halt,
the clock interrupts still happen so I guess there's no need to
invalidate the TLBs just before halt.

You could set a variable indicating you're halted and cause other
cores to send an interprocessor interrupt when a process gets
activated.  On the other hand, the non-halted cores will also
run the scheduler and pick up any recently readied process.

	Sape

[-- Attachment #2: Type: message/rfc822, Size: 3207 bytes --]

From: Sape Mullender <sape@plan9.bell-labs.com>
To: "9fans@9fans.net" <9fans@9fans.net>
Subject: Re: [9fans] why not halt in x86 multicore
Date: Mon, 4 Jul 2011 11:24:20 +0200
Message-ID: <20110704112420.16237b22@leffe.cs.bell-labs.com>

On Fri, 1 Jul 2011 19:23:03 +0200
erik quanstrom <quanstro@quanstro.net> wrote:

> 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.

I am aware of the latency issue there but in my case i care much more
about the battery of my host than about responsiveness of the guest.

So far letting it halt() works fine for me. I guess i could run into
some fun caused by missing TLB invalidation if i used that kernel on a
"real" machine. As far as i know plan9 signals the need for TLB
invalidation through a datastructure. Assuming that everybody polls
with their clock frequency.
So i guess to get it right i will have to clear the TLBs after a
halt(). Right?

Henning

  reply	other threads:[~2011-07-04  9:54 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
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 [this message]
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=c1c3d594d290ec864d92dd5e971cd86e@plan9.cs.bell-labs.com \
    --to=sape@plan9.bell-labs.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).