On Mon, Aug 10, 2009 at 08:37:03AM +0300, Sasha wrote: > We're using PERC 6 (MegaRAID SAS 1078) controller on R610 machines. When > under stress, PERC interrupts (megasas in /proc/interrupts) consume up to > 100% of CPU time on one of the cores. Usually this is CPU0, but we can > move it by writing into /proc/<megasas IRQ number>/smp_affinity file. I > was wondering if it is possible to reduce its CPU consumption, or perhaps > spread the load among several cores.
Using the smp_affinity, which is a bitmask, you can spread the interrupts across several cores, simply by setting the appropriate CPU ID bits to 1. echo "0x55" > smp_affinity would send interrupts to CPUs 1, 3, 5, and 7. For cache locality reasons, you often will actually want any given interrupt handler to run on the same core as much as possible. But if you're overloading that core, spreading them out may be beneficial. Note, for network devices, spreading the interrupts out may have an adverse impact, as then the kernel may see the arriving packets "out of order", and invoke the relatively expensive TCP packet reordering algorithms. For this reason, irqbalanced tries to keep network device interrupts pinned to a single CPU, and/or switch the device to polling mode if there's clearly enough work to do that taking an interrupt per packet would be overkill. By the same token, lwn.net this week covers an enhancement to the kernel's block I/O layer, to let it switch from interrupt mode to polling mode, which may be beneficial to workloads such as yours. This is slated for 2.6.32ish. Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux _______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge Please read the FAQ at http://lists.us.dell.com/faq
