mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Venkat Subbiah" <venkats@cranite.com>
To: "Chris Snook" <csnook@redhat.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: irq load balancing
Date: Thu, 13 Sep 2007 13:31:39 -0700	[thread overview]
Message-ID: <3641F7C576757E49AE23AD0D820D72C434DCB3@mailnode1.cranite.com> (raw)
In-Reply-To: <46E85DDA.7010209@redhat.com>

Doing it in a round-robin fashion will be disastrous for performance.
Your cache miss rate will go through the roof and you'll hit the slow
paths in the network stack most of the time.
> Most of the work in my system is spent in enrypt/decrypting traffic.
Right now all this is done in a tasklet within the softirqd and hence
all landing up on the same CPU.
On the receive side it'a packet handler that handles the traffic. On the
tx side it's done within the transmit path of the packet. So would
re-architecting this to move the rx packet handler to a different kernel
thread(with smp affinity to one CPU) and tx to a different kernel
thread(with SMP affinity to a different CPU) be advisable. 
What's the impact on cache miss and slowpath/fastpath in network stack.

Thx,
-Venkat

-----Original Message-----
From: Chris Snook [mailto:csnook@redhat.com] 
Sent: Wednesday, September 12, 2007 2:45 PM
To: Venkat Subbiah
Cc: linux-kernel@vger.kernel.org
Subject: Re: irq load balancing

Venkat Subbiah wrote:
> Most of the load in my system is triggered by a single ethernet IRQ.
> Essentially the IRQ schedules a tasklet and most of the work is done
in the
> taskelet which is scheduled in the IRQ. From what I read looks like
the
> tasklet would be executed on the same CPU on which it was scheduled.
So this
> means even in an SMP system it will be one processor which is
overloaded.
> 
> So will using the user space IRQ loadbalancer really help?

A little bit.  It'll keep other IRQs on different CPUs, which will
prevent other 
interrupts from causing cache and TLB evictions that could slow down the

interrupt handler for the NIC.

> What I am doubtful
> about is that the user space load balance comes along and changes the
> affinity once in a while. But really what I need is every interrupt to
go to
> a different CPU in a round robin fashion.

Doing it in a round-robin fashion will be disastrous for performance.
Your 
cache miss rate will go through the roof and you'll hit the slow paths
in the 
network stack most of the time.

> Looks like the APIC  can distribute IRQ's dynamically? Is this
supported in
> the kernel and any config or proc interface to turn this on/off.

/proc/irq/$FOO/smp_affinity is a bitmask.  You can mask an irq to
multiple 
processors.  Of course, this will absolutely kill your performance.
That's why 
irqbalance never does this.

	-- Chris

  reply	other threads:[~2007-09-13 20:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-11 23:18 Venkat Subbiah
2007-09-12 11:51 ` Stephen Hemminger
2007-09-12 11:55 ` kalash nainwal
2007-09-12 14:47 ` Arjan van de Ven
2007-09-12 21:44 ` Chris Snook
2007-09-13 20:31   ` Venkat Subbiah [this message]
2007-09-13 20:44     ` Lennart Sorensen
2007-09-13 21:02       ` Venkat Subbiah
2007-09-13 21:30         ` Chris Snook

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=3641F7C576757E49AE23AD0D820D72C434DCB3@mailnode1.cranite.com \
    --to=venkats@cranite.com \
    --cc=csnook@redhat.com \
    --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

all inboxes | Powered by JetHome®