All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ravikiran G Thirumalai <kiran@scalex86.org>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, discuss@x86-64.org,
	shai@scalex86.org
Subject: Re: [discuss] Re: [patch 1/3] x86_64: Node local PDA -- early cpu_to_node
Date: Fri, 2 Dec 2005 15:43:30 -0800	[thread overview]
Message-ID: <20051202234330.GA7426@localhost.localdomain> (raw)
In-Reply-To: <20051202230206.GF9766@wotan.suse.de>

On Sat, Dec 03, 2005 at 12:02:06AM +0100, Andi Kleen wrote:
> On Fri, Dec 02, 2005 at 02:51:56PM -0800, Ravikiran G Thirumalai wrote:
> > On Fri, Dec 02, 2005 at 12:43:49PM +0100, Andi Kleen wrote:
> > > And are you sure it will work with k8topology.c. Doesn't look like
> > > that to me.
> > 
> > I don't have a K8 box yet :(, so I cannot confirm either ways.  
> > But I thought newer opterons need to use  ACPI_NUMA instead...
> 
> k8topology still needs to work - e.g. for LinuxBios and users which use
> acpi=off and as a fallback for broken SRAT tables. You can't break it right now.
>

I don't think this breaks K8 per-se, because x86_cpu_to_apicid[] is setup if
acpi is compiled in and k8topology sets up apicid_to_node[] at
k8_scan_nodes. That said, I don't know for sure as I don't have a K8 yet. If
someone can test this patch on a opteron, compiled with
ACPI_NUMA as well as K8, (but which falls back to K8 at boot), 
it will be helpful.
 
> > 
> > Even if K8 detection is used, cpu_pda will have memory allocated from node0
> > which is not different from the current state.  So this patch helps Opterons
> > and EM64t boxes which use ACPI_NUMA, right?  Also the newer opteron boxes
> > and em64t NUMA boxes can now get node local memory for static per-cpu areas.
> 
> Hmm good point. However i would prefer if there was no performance regression
> between the two options. However i guess it can be kept like this now.
> Just make sure to comment it well.

Sure.

Thanks,
Kiran

  reply	other threads:[~2005-12-02 23:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-02  8:10 [patch 1/3] x86_64: Node local PDA -- early cpu_to_node Ravikiran G Thirumalai
2005-12-02  8:16 ` [patch 2/3] x86_64: Node local PDA -- Use macros to access cpu_pda Ravikiran G Thirumalai
2005-12-02  8:23 ` [patch 3/3] x86_64: Node local PDA -- allocate node local memory for pda Ravikiran G Thirumalai
2005-12-02  8:54   ` Eric Dumazet
2005-12-02 18:24     ` [discuss] " Ravikiran G Thirumalai
2005-12-02  9:05   ` Andrew Morton
2005-12-02 10:36     ` [RFC] NUMA aware kthread_create() ? Eric Dumazet
2005-12-02 12:32       ` [discuss] " Andi Kleen
2005-12-02 11:47   ` [patch 3/3] x86_64: Node local PDA -- allocate node local memory for pda Andi Kleen
2005-12-02 20:02     ` Ravikiran G Thirumalai
2005-12-02 22:41       ` Andi Kleen
2005-12-02 11:43 ` [patch 1/3] x86_64: Node local PDA -- early cpu_to_node Andi Kleen
2005-12-02 22:51   ` [discuss] " Ravikiran G Thirumalai
2005-12-02 23:02     ` Andi Kleen
2005-12-02 23:43       ` Ravikiran G Thirumalai [this message]
2005-12-02 23:48         ` Andi Kleen

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=20051202234330.GA7426@localhost.localdomain \
    --to=kiran@scalex86.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=discuss@x86-64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shai@scalex86.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.