I'll occasionally get errors in /var/log/messages indicating that irqbalance has tried to peg an interrupt to offline CPUs in SMT=1 or SMT=2 modes.
According to irqbalance documentation, I should set the IRQBALANCE_BANNED_CPUS bitmask to avoid this problem.
For a four-socket, eight core P7 system, my mask would look like 32 hexadecimal "e" characters, which on RHEL 5 can be set in /etc/sysconfig/irqbalance
I just wanted to run this by the forum to see if my logic made sense, and whether anybody else has run into this, tried this fix, or has contrary experience.
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
5 replies Latest Post - 2010-05-27T19:58:32Z by nfont
Pinned topic Avoiding SMT issues with IRQ balance
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2010-05-27T19:58:32Z at 2010-05-27T19:58:32Z by nfont
SystemAdmin 110000D4XK706 PostsACCEPTED ANSWER
Re: Avoiding SMT issues with IRQ balance2010-05-25T20:26:54Z in response to chwilkChecking. Just to be sure, is the system completely in SMT=1 or SMT=2 mode? in other words, ppc64_cpu reports the correct mode for the whole system?
# ppc64_cpu --smt smt=2
Second, is this causing any unexpected behavior?
SystemAdmin 110000D4XK706 Posts
nfont 270000FBVC1 PostACCEPTED ANSWER
Re: Avoiding SMT issues with IRQ balance2010-05-27T19:58:32Z in response to chwilkThis is pretty easy to do, and I have no problem adding this to ppc64_cpu. I do think that the logging my be better off coming from somewhere else. There are other tools that can change the smt state of the system in addition to a root users echo'ing 1's and 0's into sysfs hotplug cpus.
I think something that would catch all changes to smt state may be a better solution, but am not sure how easy that would be.