linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	Arnd Bergmann <arnd@arndb.de>, David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 1/1] network memory allocator.
Date: Fri, 18 Aug 2006 11:29:14 +0200	[thread overview]
Message-ID: <200608181129.15075.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0608171920220.28680@schroedinger.engr.sgi.com>

On Friday 18 August 2006 04:25, Christoph Lameter wrote:
> On Wed, 16 Aug 2006, Andi Kleen wrote:
> > That's not true on all NUMA systems (that they have a slow interconnect)
> > I think on x86-64 I would prefer if it was distributed evenly or maybe
> > even on the CPU who is finally going to process it.
> >
> > -Andi "not all NUMA is an Altix"
>
> The Altix NUMA interconnect has the same speed as far as I can recall as
> Hypertransport. It is the distance (real physical cable length) that
> creates latencies for huge systems. Sadly the Hypertransport is designed
> to stay on the motherboard. Hypertransport can only be said to be fast
> because its only used for tinzy winzy systems of a few processors. Are
> you saying that the design limitations of Hypertransport are an
> advantage?

Sorry, didn't want to state anything particular about advantages 
or disadvantages of different interconnects. I just wanted to say
that there are a lot of NUMA systems out there which have a very low
NUMA factor (for whatever reason, including them being quite small)
and that they should be considered for NUMA optimizations too.

So if you really want strict IO placement at least allow an easy way 
to turn it off even when CONFIG_NUMA is defined.

BTW there are large x86-64 NUMA systems that don't use HyperTransport
and have a varying NUMA factor, and also even HyperTransport
based systems have a widely varying NUMA factor depending on machine
size and hop distance (2-8 sockets and larger systems are in development)

So ideal would be something dynamic to turn on/off io placement, maybe based 
on node_distance() again, with the threshold tweakable per architecture?

Also I must say it's still not quite clear to me if it's better to place
network packets on the node the device is connected to or on the 
node which contains the CPU who processes the packet data 
For RX this can be three different nodes in the worst case
(CPU processing is often split on different CPUs between softirq
and user context), for TX  two. Do you have some experience that shows 
that a particular placement is better than the other?

-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:[~2006-08-18  9:29 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-14 11:04 Evgeniy Polyakov
2006-08-14 11:22 ` David Miller, Evgeniy Polyakov
2006-08-14 11:32   ` Evgeniy Polyakov
2006-08-14 11:40 ` Andi Kleen
2006-08-14 11:46   ` Evgeniy Polyakov
2006-08-14 12:07 ` Keith Owens
2006-08-14 12:20   ` Evgeniy Polyakov
2006-08-14 17:42     ` Rick Jones
2006-08-14 20:15       ` David Miller, Rick Jones
2006-08-14 12:25 ` Peter Zijlstra
2006-08-14 12:35   ` Evgeniy Polyakov
2006-08-14 12:38     ` Evgeniy Polyakov
2006-08-15 10:55     ` Peter Zijlstra
2006-08-15 11:26       ` Evgeniy Polyakov
2006-08-15 12:03         ` Peter Zijlstra
2006-08-15 12:34           ` Evgeniy Polyakov
2006-08-15 13:49             ` Peter Zijlstra
2006-08-15 14:15               ` Evgeniy Polyakov
2006-08-15 14:48                 ` Peter Zijlstra
2006-08-15 15:05                   ` Evgeniy Polyakov
2006-08-15 15:07                     ` Evgeniy Polyakov
2006-08-15 17:42                     ` Peter Zijlstra
2006-08-15 17:49                       ` Evgeniy Polyakov
2006-08-16  2:52                 ` Bill Fink
2006-08-16  5:38                   ` Evgeniy Polyakov
2006-08-14 17:46 ` Rick Jones
2006-08-14 19:42   ` Evgeniy Polyakov
2006-08-15  7:27 ` Andrew Morton
2006-08-15  8:08   ` Andi Kleen
2006-08-15 10:02     ` Evgeniy Polyakov
2006-08-15 10:27       ` David Miller, Evgeniy Polyakov
2006-08-15  9:20   ` Evgeniy Polyakov
2006-08-15 20:21 ` Arnd Bergmann
2006-08-16  5:35   ` Evgeniy Polyakov
2006-08-16  8:48     ` Christoph Hellwig
2006-08-16  9:00       ` Evgeniy Polyakov
2006-08-16  9:05         ` David Miller, Evgeniy Polyakov
2006-08-16  9:10           ` Christoph Hellwig
2006-08-16  9:32             ` Evgeniy Polyakov
2006-08-16  9:38               ` Christoph Hellwig
2006-08-16  9:40                 ` David Miller, Christoph Hellwig
2006-08-16  9:44                   ` Christoph Hellwig
2006-08-16  9:42         ` Christoph Hellwig
2006-08-16 11:27         ` Arnd Bergmann
2006-08-16 12:00           ` Evgeniy Polyakov
2006-08-16 12:25       ` Andi Kleen
2006-08-18  2:25         ` Christoph Lameter
2006-08-18  9:29           ` Andi Kleen [this message]
2006-08-18  8:51             ` David Miller, Andi Kleen
2006-08-18 17:04             ` Christoph Lameter
2006-08-16  7:51 ` [PATCH2 " Evgeniy Polyakov
2006-08-16 16:57   ` Stephen Hemminger
2006-08-16 19:27     ` Evgeniy Polyakov

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=200608181129.15075.ak@suse.de \
    --to=ak@suse.de \
    --cc=arnd@arndb.de \
    --cc=clameter@sgi.com \
    --cc=davem@davemloft.net \
    --cc=hch@infradead.org \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=netdev@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