[lkml]   [2004]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
On Fri, May 28, 2004 at 11:33:32AM -0700, Martin J. Bligh wrote:
> Here's my start at a list ... I'm sure it's woefully incomplete.
> 1. Utilize all CPUs roughly evenly for IRQ processing load (anything that's
> not measured by the scheduler at least, because it's unfair to other
> processes).

yep; irqbalance approximates irq processing load by irq count, which seems
to be ok-ish so far.

> Also, we may well have more than 1 CPU's worth of traffic to
> process in a large network server.

One NIC? I've yet to see that ;)

> 2. Provide some sort of cache-affinity for network interrupt processing,
> which also helps us not get into out-of-order packet situations.

yep; irqbalance does that

> 3. Utilize idle CPUs where possible to shoulder the load.

this is in direct conflict with 2; esp since cpus are idle very short times
all the time in busy scenarios (and non-busy scenarios are boring wrt irq
loadf ;)

> 4. Provide such a solution for all architectures.

irqbalanced in principle arch independent since the /proc interface is quite
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 14:03    [W:0.055 / U:2.316 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site