Messages in this thread | | | Date | Fri, 28 May 2004 21:01:29 +0200 | From | Arjan van de Ven <> | Subject | Re: CONFIG_IRQBALANCE for AMD64? |
| |
On Fri, May 28, 2004 at 11:57:24AM -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. >
> 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?
irqbalance uses class based balancing to try to balance the "some are heavier than others" thing.
> > >> 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 ...
yeah, and if you have more than 1 cpu, irqbalanced *will* spread them.
> 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? ;-)
the userspace one is quite different and uses different level of information (for example it makes class groups of irq's, eg it groups all ethernet irq's, all storage irq's etc in separate classes and uses the class info in the balancing algorithm). That surely is beyond what you'd want to do inside the kernel, but it works great ;)
[unhandled content-type:application/pgp-signature] | |