On 5/10/2013 3:39 AM, Guy Marcenac wrote: > Le 09/05/2013 17:34, Stan Hoeppner a écrit : >> Or simply cron a stop/start of irqbalance some x minutes after bootup. > > Thank you Stan > > I tryied restarting irqbalance on my running system with > /etc/init.d/irqbalance restart > But the warning still appears in the log... > > I think I will wait for an update since I understand that not having > irqbalance running does not harm the system.
It was discovered some time back that IO would not scale as it should on many/most busy systems, because all the interrupts were being routed by the PC platform chipsets to CPU0 and swamping it, limiting IO throughput to a fraction of the hardware capability. This default IRQ routing to CPU0 is an Intel platform spec from long ago and every PC based system does this. This is especially a problem on systems such as those sporting lots of sockets and cores, such as an AMD system w/4 sockets/48 low TDP cores at only 1.7GHz, with say 10 PCIe x8/16 slots. It doesn't take that much IO across the HBAs to saturate a 1.7GHz Magny Cours core with IRQ processing. irqbalance was written to remap the chipset routing table such that IRQs from an HBA could be mapped to a specific CPU or a core within a CPU, eliminating the congestion at CPU0. Thus, unless a system has both multiple sockets/cores and multiple HBAs (SAS, RAID, FC, Infiniband, GbE/10GbE), with lots of sustained IO and thus interrupts, then irqbalance is really irrelevant. It's not needed in desktops, nor most average servers, especially those with high clock rate CPUs. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518cbe91.9080...@hardwarefreak.com
