The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Cc: Ashok Raj <ashok.raj@intel.com>, Andrew Morton <akpm@osdl.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch 13/14] x86_64: Use common functions in cluster and physflat mode
Date: 10 Sep 2005 02:30:22 +0200
Date: Sat, 10 Sep 2005 02:30:22 +0200	[thread overview]
Message-ID: <20050910003022.GB61151@muc.de> (raw)
In-Reply-To: <Pine.LNX.4.61.0509091003490.978@montezuma.fsmlabs.com>

On Fri, Sep 09, 2005 at 10:07:28AM -0700, Zwane Mwaikambo wrote:
> On Tue, 6 Sep 2005, Ashok Raj wrote:
> 
> > On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote:
> > > On Sat, Sep 03, 2005 at 02:33:30PM -0700, akpm@osdl.org wrote:
> > > > 
> > > > From: Ashok Raj <ashok.raj@intel.com>
> > > > 
> > > > Newly introduced physflat_* shares way too much with cluster with only a very
> > > > differences.  So we introduce some common functions in that can be reused in
> > > > both cases.
> 
> On a slightly different topic, how come we're using physflat for hotplug 
> cpu?

The original idea was to always use physflat mode for hotplug because
that does all the sequencing stuff and avoids the shortcut races.
But then Ashok decided it was better to add more ifdefs to flat mode
instead and I gave up protesting at some point.

-Andi

> 
> -#ifndef CONFIG_CPU_HOTPLUG
>  		/* In the CPU hotplug case we cannot use broadcast mode
>  		   because that opens a race when a CPU is removed.
> -		   Stay at physflat mode in this case.
> -		   It is bad to do this unconditionally though. Once
> -		   we have ACPI platform support for CPU hotplug
> -		   we should detect hotplug capablity from ACPI tables and
> -		   only do this when really needed. -AK */
> +		   Stay at physflat mode in this case. - AK */
> +#ifdef CONFIG_HOTPLUG_CPU
>  		if (num_cpus <= 8)
>  			genapic = &apic_flat;
> 
> Thanks,
> 	Zwane
> 

  parent reply	other threads:[~2005-09-10  0:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200509032135.j83LZ8gX020554@shell0.pdx.osdl.net>
     [not found] ` <20050905231628.GA16476@muc.de>
2005-09-06 23:12   ` [patch 13/14] x86_64: Use common functions in cluster and physflat mode Ashok Raj
2005-09-09 17:07     ` Zwane Mwaikambo
2005-09-09 20:45       ` Ashok Raj
2005-09-11 16:44         ` Zwane Mwaikambo
2005-09-11 23:02           ` Andi Kleen
2005-09-12 22:23             ` Ashok Raj
2005-09-13  8:10               ` Andi Kleen
2005-09-13 14:53                 ` Zwane Mwaikambo
2005-09-13 15:31                   ` Andi Kleen
2005-09-10  0:30       ` Andi Kleen [this message]
2005-09-10  1:51         ` Zwane Mwaikambo

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=20050910003022.GB61151@muc.de \
    --to=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=ashok.raj@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --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