Need to backport this patch: https://lkml.org/lkml/2011/10/6/275 So that we can make use of the latest version of irqbalance.
(In reply to comment #0) > Need to backport this patch: > https://lkml.org/lkml/2011/10/6/275 > > So that we can make use of the latest version of irqbalance. And we want to use the latest version of irqbalance because? Since you're already on v5 of the patch, can you wait until it gets into an upstream tree before you backport it? Also, if this is going into 3.2 then rawhide is going to be there pretty quick... it'll either be a very short-lived patch or the version in this bug is wrong.
http://git.kernel.org/?p=linux/kernel/git/jbarnes/pci.git;a=commit;h=933aa5c1f69aa650f59ba783307fc7ed7cc5fafa There it is. IT probably will be a pretty short lived patch (although I plan on pulling this into f16 as well) As for the reason to use the latest irqbalance, its because the current version (0.56 is completely broken). It can't recognize msi irqs properly and associate them with devices, and with the advent of biosdevname, it can't consistently determine what class of device various irq's belong to. In short, it can't balance interrupts properly, and winds up causing more harm than good to system performance. The latest version of irqbalance corrects that.
(In reply to comment #2) > http://git.kernel.org/?p=linux/kernel/git/jbarnes/pci.git;a=commit;h=933aa5c1f69aa650f59ba783307fc7ed7cc5fafa > > There it is. IT probably will be a pretty short lived patch (although I plan > on pulling this into f16 as well) OK. I can try to get it into rawhide later today. > As for the reason to use the latest irqbalance, its because the current version > (0.56 is completely broken). It can't recognize msi irqs properly and > associate them with devices, and with the advent of biosdevname, it can't > consistently determine what class of device various irq's belong to. In short, > it can't balance interrupts properly, and winds up causing more harm than good > to system performance. The latest version of irqbalance corrects that. Is there some coordination we need to do with the irqbalance package? If we add the patch, will things go horribly wrong with an older version of userspace or is the patch fairly stand-alone and irqbalance can cope with either kind of kernel? I ask because F15 and F16 are both based on 3.1 at this point, so if we need to coordinate I'd like to make sure all the releases are lined up properly.
> OK. I can try to get it into rawhide later today. No worries, I've almost got it done, I'll commit it shortly >Is there some coordination we need to do with the irqbalance package? If we >add the patch, will things go horribly wrong with an older version of userspace >or is the patch fairly stand-alone and irqbalance can cope with either kind of >kernel? The latter. Irqbalance just uses this patch to associate msi irqs to devices, for the purposes of determining which numa node is optimal for that irq. In its absence, irq just round robins irqs around all the nodes, which is sub-optimal, but still perfectly functional. Irqbalance-1.0 has been in F16 and rawhide for a few weeks now without incident, so this patch is really more of a 'nice to have' more than anything :)
In today's rawhide build. Thanks Neil.