public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jesse.barnes@intel.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC] pcibus_to_node implementation for ia64
Date: Wed, 11 May 2005 15:54:35 +0000	[thread overview]
Message-ID: <200505110854.36023.jesse.barnes@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0505051707220.6114@schroedinger.engr.sgi.com>

On Wednesday, May 11, 2005 8:44 am, colin ngam wrote:
> Fine line here .. a valid node id is always returned and that nodeid
> is a vaild node id for addressing the bus/devices and may be the only
> node id you can use to address these buses and devices, except when
> the IO Brick is dual ported.  It is valid with respect to addressing
> the bus/devices but may not be "valid" with respect to "having
> Memory" or "having cpus".  Depends on what you expect :-)  Depends on
> how you want to use it :-)

But not valid in the sense that you can pass it to any of the kernel 
routines that say they take a 'node' argument.  IMO, that's a bug in 
the implementation of I/O and memoryless nodes in sn2.  As Jack and I 
discussed last year at OLS (he convinced me of this), a node is any 
combination of memory, CPUs, and/or I/O.  If I/O nodes (or nodes w/o 
memory generally) are special cased, we're breaking that assumption, 
making things harder for every caller and user of nodes.

> >That's certainly another way to go--just make the function do a
> > search to find the closest node with memory (and/or CPUs) all by
> > itself.  The obvious disadvantage is that you'll incur that cost on
> > every function call unless you build a lookup table at boot time or
> > somesuch.
>
> How often do you do this to worry about latency?

Not sure, but the search could get pretty expensive so it's probably 
best to avoid it just to give callers flexibility.

Jesse

  parent reply	other threads:[~2005-05-11 15:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-06  0:12 [RFC] pcibus_to_node implementation for ia64 Christoph Lameter
2005-05-10 23:56 ` colin ngam
2005-05-11  1:34 ` Christoph Lameter
2005-05-11  2:42 ` colin ngam
2005-05-11  6:51 ` Christoph Lameter
2005-05-11 15:29 ` Jesse Barnes
2005-05-11 15:44 ` colin ngam
2005-05-11 15:49 ` Christoph Lameter
2005-05-11 15:52 ` colin ngam
2005-05-11 15:54 ` Jesse Barnes [this message]
2005-05-11 15:58 ` Jesse Barnes
2005-05-11 16:05 ` colin ngam
2005-05-11 16:19 ` Jack Steiner

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=200505110854.36023.jesse.barnes@intel.com \
    --to=jesse.barnes@intel.com \
    --cc=linux-ia64@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