public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Ashok Raj <ashok.raj@intel.com>
Cc: zwane@arm.linux.org.uk, discuss@x86-64.org, shaohua.li@intel.com,
	linux-kernel@vger.kernel.org, rusty@rustycorp.com.au,
	vatsa@in.ibm.com
Subject: Re: [discuss] Re: [patch 0/4] CPU hot-plug support for x86_64
Date: 24 May 2005 13:48:12 +0200
Date: Tue, 24 May 2005 13:48:12 +0200	[thread overview]
Message-ID: <20050524114812.GA86233@muc.de> (raw)
In-Reply-To: <20050523104046.B8692@unix-os.sc.intel.com>

On Mon, May 23, 2005 at 10:40:46AM -0700, Ashok Raj wrote:
> On Mon, May 23, 2005 at 07:12:12PM +0200, Andi Kleen wrote:
> > > The only other workable alternate would be to use the stop_machine() 
> > > like thing which we use to automically update cpu_online_map. This means we 
> > > execute a high priority thread on all cpus, bringing the system to knees before
> > 
> > That is not nice agreed.
> > 
> > > just adding a new cpu. On very large systems this will definitly be 
> > > visible.
> > 
> > I still dont quite get it why it is not enough to keep interrupts
> > off until the CPU enters idle. Currently we enable them shortly
> > in the middle of the initialization (whcih is already dangerous
> > because interrupts can see half initialized state like out of date TSC),
> > but I hope to get rid of that soon too. With the full startup
> > in CLI would you problems be gone?
> > 
> 
> I think so, if we can ensure none is delivered to the partially up cpu
> we probably are covered.

You mean not delivered to its APIC or not delivered as an visible
interrupt in the instruction stream?

The later can be ensured, the first not. I guess if the first is a problem
you could add a function to ack all pending interrupts after initial sti.

e.g. we can assume the CPU will deliver everything pending after two
instruction after the sti and when there are interrupts left in the APIC 
you can ack them. But why would they not be raised as real interruptions
at this point anyways?


> Iam not a 100% sure about above either, if the smp_call_function 
> is started with 3 cpus initially, and 1 just came up, the counts in 
> the smp_call data struct could be set to 3 as a result of the new cpu 
> received this broadcast as well, and we might quit earlier in the wait.

In the worst case a smp_call_function would be delayed for the whole
boot up time of a new CPU which should be quite bounded. The longest
delay in there is probably the bogomips calibrate, but I believe
Venkatesh recently sped that up greatly anyways so it should not be 
an issue anymore. If the delay is < 1s that is probably tolerable.

Or do I miss some shade of the problem you are worried about?

-Andi

  parent reply	other threads:[~2005-05-24 11:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-20 22:16 [patch 0/4] CPU hot-plug support for x86_64 Ashok Raj
2005-05-20 22:16 ` [patch 1/4] " Ashok Raj
2005-05-20 22:16 ` [patch 2/4] " Ashok Raj
2005-05-23 16:38   ` Andi Kleen
2005-05-23 16:58     ` Ashok Raj
2005-05-23 17:24       ` Andi Kleen
2005-05-23 17:32         ` Ashok Raj
2005-05-23 19:37     ` Rafael J. Wysocki
2005-05-24 11:49       ` Andi Kleen
2005-05-20 22:16 ` [patch 3/4] " Ashok Raj
2005-05-20 22:16 ` [patch 4/4] " Ashok Raj
2005-05-23 16:40 ` [patch 0/4] " Andi Kleen
2005-05-23 16:54   ` Ashok Raj
2005-05-23 17:12     ` Andi Kleen
2005-05-23 17:40       ` [discuss] " Ashok Raj
2005-05-24  5:46         ` Srivatsa Vaddagiri
2005-05-24  6:01           ` Ashok Raj
2005-05-24  8:53             ` Srivatsa Vaddagiri
2005-05-24 18:17               ` Andi Kleen
2005-05-24 11:50           ` Andi Kleen
2005-05-24 11:48         ` Andi Kleen [this message]
2005-05-24 17:01           ` Srivatsa Vaddagiri

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=20050524114812.GA86233@muc.de \
    --to=ak@muc.de \
    --cc=ashok.raj@intel.com \
    --cc=discuss@x86-64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustycorp.com.au \
    --cc=shaohua.li@intel.com \
    --cc=vatsa@in.ibm.com \
    --cc=zwane@arm.linux.org.uk \
    /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