All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: David Miller <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"arjan@linux.jf.intel.com" <arjan@linux.jf.intel.com>,
	"mingo@elte.hu" <mingo@elte.hu>,
	"yong.zhang0@gmail.com" <yong.zhang0@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH v2] irq: Add node_affinity CPU masks for smarter irqbalance hints
Date: Mon, 30 Nov 2009 09:24:02 -0800	[thread overview]
Message-ID: <1259601842.2172.4.camel@localhost> (raw)
In-Reply-To: <alpine.LFD.2.00.0911242317280.24119@localhost.localdomain>

On Tue, 2009-11-24 at 14:23 -0800, Thomas Gleixner wrote:
> On Tue, 24 Nov 2009, Peter P Waskiewicz Jr wrote:
> > On Tue, 2009-11-24 at 13:56 -0800, Thomas Gleixner wrote:
> > > On Tue, 24 Nov 2009, David Miller wrote:
> > > 
> > > > From: Thomas Gleixner <tglx@linutronix.de>
> > > > Date: Tue, 24 Nov 2009 12:07:35 +0100 (CET)
> > > > 
> > > > > And what does the kernel do with this information and why are we not
> > > > > using the existing device/numa_node information ?
> > > > 
> > > > It's a different problem space Thomas.
> > > > 
> > > > If the device lives on NUMA node X, we still end up wanting to
> > > > allocate memory resources (RX ring buffers) on other NUMA nodes on a
> > > > per-queue basis.
> > > > 
> > > > Otherwise a network card's forwarding performance is limited by the
> > > > memory bandwidth of a single NUMA node, and on a multiqueue cards we
> > > > therefore fare much better by allocating each device RX queue's memory
> > > > resources on a different NUMA node.
> > > > 
> > > > It is this NUMA usage that PJ is trying to export somehow to userspace
> > > > so that irqbalanced and friends can choose the IRQ cpu masks more
> > > > intelligently.
> > > 
> > > So you need a preferred irq mask information on a per IRQ basis and
> > > that mask is not restricted to the CPUs of a single NUMA node, right ?
> > > 
> > Just to clarify, I need a preferred CPU mask on a per IRQ basis.  And
> > yes, that mask may not be restricted to the CPUs of a single NUMA node.
> > But in the normal case, the mask will be restricted to CPUs of a single
> > node.
> 
> Right, but the normal case does not help much if we need to consider
> the special case of multiple nodes affected which requires another
> cpumask in irq_desc. That's what I really want to avoid.
> 
> I at least understand the exact problem you guys want to solve. Will
> think more about it.
> 

Just a friendly ping Thomas.  Any progress on your thinking about this
proposal?

Cheers,
-PJ


      reply	other threads:[~2009-11-30 17:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24  9:35 [PATCH v2] irq: Add node_affinity CPU masks for smarter irqbalance hints Peter P Waskiewicz Jr
2009-11-24 11:07 ` Thomas Gleixner
2009-11-24 17:57   ` David Miller
2009-11-24 21:56     ` Thomas Gleixner
2009-11-24 22:05       ` Peter P Waskiewicz Jr
2009-11-24 22:23         ` Thomas Gleixner
2009-11-30 17:24           ` Peter P Waskiewicz Jr [this message]

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=1259601842.2172.4.camel@localhost \
    --to=peter.p.waskiewicz.jr@intel.com \
    --cc=arjan@linux.jf.intel.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=yong.zhang0@gmail.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.