public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Mike Travis <travis@sgi.com>
Cc: Andi Kleen <andi@firstfloor.org>, Yinghai Lu <Yinghai.Lu@Sun.COM>,
	Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	lameter@sgi.com
Subject: Re: [PATCH] x86_64: remove never used nodenumer in pda
Date: Tue, 19 Feb 2008 21:59:38 +0100	[thread overview]
Message-ID: <20080219205938.GC13958@one.firstfloor.org> (raw)
In-Reply-To: <47BB20C6.7050205@sgi.com>

On Tue, Feb 19, 2008 at 10:32:38AM -0800, Mike Travis wrote:
> Andi Kleen wrote:
> > On Tue, Feb 19, 2008 at 07:48:54AM -0800, Mike Travis wrote:
> >> Andi Kleen wrote:
> >>> Yinghai Lu <Yinghai.Lu@Sun.COM> writes:
> >>>
> >>>> we don't need copy too. already have x86_cpu_to_node_map
> >>> That's a regression (probably from Mike's patches?). Until recently it was 
> >>> used.
> >> Yes, I had removed it because I couldn't find any references to it.
> > 
> > Hmm, maybe it regressed earlier. Sorry if I blamed you incorrectly.
> > Anyways at some point this definitely worked. I remember writing
> > the code ;-) 
> > 
> >> And reading one's own percpu variables should be as efficient as
> >> reading one's own pda.
> > 
> > Sure, but the point is that getting the current node is a common
> > operation, so it should be a single reference and not go through a 
> > lookup table.
> > 
> > How it is actually implemented -- through PDA or through you new
> > equivalent per cpu variables -- does not really matter as long 
> > as the resulting code is only a single instruction. Using
> > the lookup array from the cpu number is wrong.
> > 
> > My patch just fixed it back to use the PDA in the old style for now,
> > but if all your per cpu stuff is merged (I admit I haven't tracked 
> > if it is or not) replacing that with a per cpu variable would work too
> > if it then generates the same code as with PDA.
> > 
> > -Andi
> 
> I'll look at it some more as I don't really have a preference either.
> One thing that also bothered me was other cpus read the per cpu
> variable to get the node number whilst the current cpu reads the pda
> variable.  I'll see about resolving that quirky-ness.  (All one or all
> the other.)

This information should always come from the same variable.

> (And of course the problem with cpus on nodes with no local memory
> needs to be resolved as well.)

All CPUs get assigned to some node at boot.

And there should be always per cpu variables or pda to use.

-Andi

  reply	other threads:[~2008-02-19 20:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-17  7:02 [PATCH] x86_64: remove never used nodenumer in pda Yinghai Lu
2008-02-17 14:03 ` Thomas Gleixner
2008-02-18 12:23 ` Andi Kleen
2008-02-18 20:16   ` Yinghai Lu
2008-02-19 15:48   ` Mike Travis
2008-02-19 18:08     ` Andi Kleen
2008-02-19 18:32       ` Mike Travis
2008-02-19 20:59         ` Andi Kleen [this message]
2008-02-19 21:37           ` Mike Travis

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=20080219205938.GC13958@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=Yinghai.Lu@Sun.COM \
    --cc=akpm@linux-foundation.org \
    --cc=lameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=travis@sgi.com \
    /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