Red Hat Bugzilla – Full Text Bug Listing
|Summary:||add s390 and s390x into ExclusiveArch|
|Product:||[Fedora] Fedora||Reporter:||Dan Horák <dan>|
|Component:||irqbalance||Assignee:||Neil Horman <nhorman>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||9||CC:||dennis, gmuelas, nhorman|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-11-06 14:35:42 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Dan Horák 2008-11-06 04:19:51 EST
Please add s390 and s390x into ExclusiveArch, because irqbalance does work/compile there. Adding dgilmore to CC as he can require/decline similar action for Fedora on Sparc.
Comment 1 Neil Horman 2008-11-06 14:35:42 EST
I believe that it compiles and even runs without error on s390 (given that its only interface to the kernel is via /proc). That being said however, I can't find any reason why its usefull on those arches. While one can steer interrupts to various cpus in a guest account (either via irqbalance, or manually via /proc/irq/<irq #>/smp_affinity), theres no guarantee that those interrupts will actually be steered to different physical cpus. Since you're always running on a hypervisor on these arches, theres always going to be a disconnect between what irqblance tries to do and what acutally happens on the metal. If you can come up with some evidence that irqbalance produces a benefit on these systems consistently and predictably, then I'll happily consider it, but just the fact that its runs without falling over isn't reason enough to enable it.
Comment 2 Gonzalo Muelas Serrano 2008-11-10 09:57:00 EST
From what I understood from one of our s390[x] kernel developers, he agrees with Neil: the interrupts in s390 are floating interrupts, that is, is not possible/there is no intention to choose the CPU, so s390x won't benefit form irqbalance.