[lkml]   [2004]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
>> 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.

Isn't that exactly what the in-kernel one does though? which people were
complaining about (wrt network backend (softirq?) processing)? And some interrupts are much heavier than others, surely?

>> 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 ;)

No, multiple NICs. but if I shove 8 gigabit adaptors in a machine, we need
more than 1 cpu to process it ...

>> 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 ;)

Mmmm. for benchmarking scenarios, maybe ... but I do believe than machines
aren't maxed out all the time. definitely a problem to determine how long
the idle interval is though. Past history might be a clue, but ... yes, not

>> 4. Provide such a solution for all architectures.
> irqbalanced in principle arch independent since the /proc interface is quite
> generic..

In principle either way *could* be arch independant ... though the in-kernel
one certainly isn't right now.

Is there actually any algorithmic difference between the user-space and
in-kernel ones? or is this just a philosophical debate about user vs kernel
placement of code? ;-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:03    [W:0.063 / U:1.924 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site