> Which brings up an interesting question --- why do we have an IRQ
> balancer in the kernel at all?
good question; at least RHEL disables it and uses the userspace one
(which only decides to change the balance at most every 10 seconds, but
has a strong tendency to leave the irqs as they are)
> but spreading IRQ's across all of the CPU's doesn't seem like it's
> ever the right answer.
well it is in some cases, imagine having 2 cpus and 2 gige nics that are
very busy doing webserving. That's an obvious case where 1-nic-per-cpu
ends up doing the right thing... the way it ends up is that each nic has
a full cpu for itself and it's own apaches... almost fully independent
of the other one. Now if you moved both irqs to the same cpu, the
apaches would follow, because if they didn't then you'd be bouncing
their data *all the time*. And at that point the other cpu will become
bored ;)
This is what the userspace irqbalance has in its policy more or less:
spread the irqs within the same class to different processors. And as
secondary policy it tries to spread it out a bit, but that's only
secondary.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
