public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Dobson <colpatch@us.ibm.com>
To: Erich Focht <efocht@ess.nec.de>
Cc: davidm@hpl.hp.com, linux-ia64 <linux-ia64@linuxia64.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] topology for ia64
Date: Tue, 29 Oct 2002 14:19:25 -0800	[thread overview]
Message-ID: <3DBF096D.6080703@us.ibm.com> (raw)
In-Reply-To: 200210221123.37145.efocht@ess.nec.de

Erich Focht wrote:
> On Tuesday 22 October 2002 02:07, David Mosberger wrote:
> 
>>Why does the cpu_to_node_map[] exist for non-NUMA configurations?  It
>>seems to me that it would be better to make cpu_to_node_map a macro
>>that uses an array-check for NUMA configurations and a simple test
>>against phys_cpu_present_map() for non-NUMA.
> 
> Attached is a modified patch for implementing the topology stuff on ia64.
> It's on top of your 2.5.39 tree including acpi_numa and the acpi_numa fix
> which I've sent you separately.
> 
> I dropped the cpu_to_node_map array for the non-NUMA case. The macro
> __cpu_to_node() returns 0 in this case. In the places where it is used
> (e.g. in the NUMA scheduler) we either run on a valid CPU or have
> cpu_online() checks before using it, therefore I also removed the
> phys_cpu_present_map check when building the cpu to node map.

Hi Erich!  Apologies for the long response delay...  I think our mail 
server must be a bit lagged.  ;)

It looks good to me.  As far as this comment:
+/*
+ * Returns the number of the first CPU on Node 'node'.
+ * Slow in the current implementation.
+ * Who needs this?
+ */
+/* #define __node_to_first_cpu(node) pool_cpus[pool_ptr[node]] */
+static inline int __node_to_first_cpu(int node)

No one is using it now.  I think that I will probably deprecate this 
function in the near future as it is pretty useless.  Anyone looking for 
that functionality can just do an __ffs(__node_to_cpu_mask(node)) 
instead, and hope that there is a reasonably quick implementation of 
__node_to_cpu_mask.


> Hope this can be included now...

I agree!  Linus or another maintainer, please pick this up.  These 
macros should be implemented intelligently on as many architectures as 
possible, now that they're beginning to be used in more and more places.

Cheers!

-Matt

> 
> Regards,
> Erich
 >
 > <patch snip>
 >


  reply	other threads:[~2002-10-29 22:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-05 17:04 [PATCH] topology for ia64 Erich Focht
2002-10-22  0:07 ` David Mosberger
2002-10-22  9:23   ` Erich Focht
2002-10-29 22:19     ` Matthew Dobson [this message]
2002-10-29 22:35       ` [Linux-ia64] " Michael Hohnbaum
2002-10-29 23:55         ` Matthew Dobson
2002-10-29 22:47       ` William Lee Irwin III
2002-10-30  0:01         ` Matthew Dobson
2002-10-29 23:43       ` Erich Focht

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=3DBF096D.6080703@us.ibm.com \
    --to=colpatch@us.ibm.com \
    --cc=davidm@hpl.hp.com \
    --cc=efocht@ess.nec.de \
    --cc=linux-ia64@linuxia64.org \
    --cc=linux-kernel@vger.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