public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Haicheng Li <haicheng.li@linux.intel.com>
To: David Rientjes <rientjes@google.com>
Cc: Ingo Molnar <mingo@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	x86@kernel.org, Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [patch] x86: set hotpluggable nodes in nodes_possible_map
Date: Thu, 21 Jan 2010 16:33:36 +0800	[thread overview]
Message-ID: <4B581160.2090209@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1001202344580.29982@chino.kir.corp.google.com>

David Rientjes wrote:
> On Thu, 21 Jan 2010, Haicheng Li wrote:
> 
>>> Nack, we don't need to add yet another nodemask because you're having
>>> trouble finding a new name for a cpu_nodes_parsed.  It would be perfectly 
>> Hey Dave, why do you think it's just a naming issue?
>>
>> What I'm concerning is that your assumption of cpu_nodes_parsed use is wrong,
>> cpu_nodes_parsed is needed anyway since its semantics represent the node with
>> cpu affinity rather than memless node, that's also why I originally doubted
>> cpu_node_parsed cannot handle hotplug node.
> 
> Wrong, cpu_nodes_parsed (despite its name) solely represents nodes that do 
> not have online address memory ranges.  That's it.  Nothing more, nothing 
> less.  That's why I suggest you rename it to no_mem_nodes or something 
> similar.  Look at the single time that the nodemask is used: to set 
> cleared bits in node_possible_map that were not set in nodes_parsed 
> because THEY DO NOT HAVE ASSOCIATED ONLINE MEMORY RANGES, the _only_ time 
> a node gets set in nodes_parsed.
> 
> Once you rename nodes_parsed to mem_nodes and cpu_nodes_parsed to 
> no_mem_nodes, it may become clearer.
> 
>> we also need hp_nodes_parsed to represent the node with hotpluggable memory
>> region, just like why we need nodes_parsed to repsent node with mem on.
>>
> 
> It's pointless to add another nodemask, the semantics of cpu_nodes_parsed 
> is perfectly legitimate for hotpluggable nodes as well.  Instead of 
> fixating on the name, look at the code that uses it.

I'm not meant to be rude, but it's illogical excuse. that it is now used by a single function 
doesn't mean that it will never be used by others in future or it is only useful for that single 
function.

see the code, we can find such relationships between related data-structures.
- struct bootnode nodes[] -> nodes_parsed
all the node in nodes_parsed should have a relative mem range in nodes[].

- apicid_to_node[] -> cpu_nodes_parsed
all the value of apicid_to_node[] should be valid in cpu_nodes_parsed. If we put hotpluggable node 
into cpu_nodes_parsed, such relationship is broken, right?

- nodes_add[] -> ?? (this is for hotpluggable node)
all the hotplugged mem can find a corresponding node thru nodes_add[].

-haicheng

  reply	other threads:[~2010-01-21  8:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-15  7:42 [PATCH] x86/mm/srat_64.c: nodes_parsed should include all nodes detected by ACPI Haicheng Li
2010-01-17  2:22 ` Haicheng Li
2010-01-17 21:53 ` David Rientjes
2010-01-18  6:30   ` Yinghai Lu
2010-01-18 10:43     ` David Rientjes
2010-01-19 11:08       ` Haicheng Li
2010-01-19 11:29         ` Haicheng Li
2010-01-19 23:30         ` David Rientjes
2010-01-20 16:40           ` Haicheng Li
2010-01-20 20:10             ` [patch] x86: set hotpluggable nodes in nodes_possible_map David Rientjes
2010-01-20 22:45               ` Yinghai Lu
2010-01-20 23:32                 ` David Rientjes
2010-01-21  3:00                 ` Haicheng Li
2010-01-21  2:58               ` Haicheng Li
2010-01-21  6:58                 ` David Rientjes
2010-01-21  7:31                   ` Haicheng Li
2010-01-21  7:50                     ` David Rientjes
2010-01-21  8:33                       ` Haicheng Li [this message]
2010-01-21 23:12                         ` David Rientjes
2010-01-22  4:06                           ` [PATCH] x86/mm/srat_64.c: make node_possible_map include hotpluggable node Haicheng Li
2010-01-22  7:33                             ` H. Peter Anvin
2010-01-22  8:43                               ` Haicheng Li
2010-01-22 10:14                                 ` H. Peter Anvin
2010-01-22 10:35                                   ` Haicheng Li
2010-01-22 11:15               ` [tip:x86/urgent] x86: Set hotpluggable nodes in nodes_possible_map tip-bot for David Rientjes
2010-01-23  6:51               ` tip-bot for David Rientjes

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=4B581160.2090209@linux.intel.com \
    --to=haicheng.li@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox