All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Ethan Solomita <solo@google.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/1] mm: Inconsistent use of node IDs
Date: Tue, 13 Mar 2007 00:19:30 +0100	[thread overview]
Message-ID: <200703130019.30953.ak@suse.de> (raw)
In-Reply-To: <45F5D974.2050702@google.com>

On Monday 12 March 2007 23:51, Ethan Solomita wrote:
> This patch corrects inconsistent use of node numbers (variously "nid" or
> "node") in the presence of fake NUMA.

I think it's very consistent -- your patch would make it inconsistent though.

> Both AMD and Intel x86_64 discovery code will determine a CPU's physical
> node and use that node when calling numa_add_cpu() to associate that CPU
> with the node, but numa_add_cpu() treats the node argument as a fake
> node. This physical node may not exist within the fake nodespace, and
> even if it does, it will likely incorrectly associate a CPU with a fake
> memory node that may not share the same underlying physical NUMA node.
> 
> Similarly, the PCI code which determines the node of the PCI bus saves
> it in the pci_sysdata structure. This node then propagates down to other
> buses and devices which hang off the PCI bus, and is used to specify a
> node when allocating memory. The purpose is to provide NUMA locality,
> but the node is a physical node, and the memory allocation code expects
> a fake node argument.

Sorry, but when you ask for NUMA emulation you will get it. I don't see
any point in a "half way only for some subsystems I like" NUMA emulation. 
It's unlikely that your ideas of where it is useful and where is not
matches other NUMA emulation user's ideas too.

Besides adding such a secondary node space would be likely a huge long term 
mainteance issue. I just can it see breaking with every non trivial change.

NACK.

-Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@suse.de>
To: Ethan Solomita <solo@google.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/1] mm: Inconsistent use of node IDs
Date: Tue, 13 Mar 2007 00:19:30 +0100	[thread overview]
Message-ID: <200703130019.30953.ak@suse.de> (raw)
In-Reply-To: <45F5D974.2050702@google.com>

On Monday 12 March 2007 23:51, Ethan Solomita wrote:
> This patch corrects inconsistent use of node numbers (variously "nid" or
> "node") in the presence of fake NUMA.

I think it's very consistent -- your patch would make it inconsistent though.

> Both AMD and Intel x86_64 discovery code will determine a CPU's physical
> node and use that node when calling numa_add_cpu() to associate that CPU
> with the node, but numa_add_cpu() treats the node argument as a fake
> node. This physical node may not exist within the fake nodespace, and
> even if it does, it will likely incorrectly associate a CPU with a fake
> memory node that may not share the same underlying physical NUMA node.
> 
> Similarly, the PCI code which determines the node of the PCI bus saves
> it in the pci_sysdata structure. This node then propagates down to other
> buses and devices which hang off the PCI bus, and is used to specify a
> node when allocating memory. The purpose is to provide NUMA locality,
> but the node is a physical node, and the memory allocation code expects
> a fake node argument.

Sorry, but when you ask for NUMA emulation you will get it. I don't see
any point in a "half way only for some subsystems I like" NUMA emulation. 
It's unlikely that your ideas of where it is useful and where is not
matches other NUMA emulation user's ideas too.

Besides adding such a secondary node space would be likely a huge long term 
mainteance issue. I just can it see breaking with every non trivial change.

NACK.

-Andi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-03-12 23:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-12 22:51 [PATCH 1/1] mm: Inconsistent use of node IDs Ethan Solomita
2007-03-12 22:51 ` Ethan Solomita
2007-03-12 23:19 ` Andi Kleen [this message]
2007-03-12 23:19   ` Andi Kleen
2007-03-12 23:54   ` Ethan Solomita
2007-03-12 23:54     ` Ethan Solomita
2007-03-16 20:26     ` Ethan Solomita
2007-03-16 20:26       ` Ethan Solomita

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=200703130019.30953.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=solo@google.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 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.