linux-kernel - [RFC] irqbalance: Mark in-kernel irqbalance as obsolete, set to N by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <44CE3F5E.4010305@intel.com>
Date:	Mon, 31 Jul 2006 10:35:26 -0700
From:	Auke Kok <auke-jan.h.kok@...el.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
CC:	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	Auke Kok <auke-jan.h.kok@...el.com>,
	NetDev <netdev@...r.kernel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: [RFC] irqbalance: Mark in-kernel irqbalance as obsolete, set to N
 by default

We've recently seen a number of user bug reports against e1000 that the 
in-kernel irqbalance code is detrimental to network latency. The algorithm 
keeps swapping irq's for NICs from cpu to cpu causing extremely high network 
latency (>1000ms). Another NIC driver (cxgb) already has severe warnings in 
their documentation file against using CONFIG_IRQBALANCE, but this is a 
general problem for all NIC drivers and other subsystems. This is especially 
so with cpufreq scaling where the system is slowed down and the migrations 
take much longer.

I suggest that the in-kernel irqbalance is phased out, by marking it OBSOLETE 
first and (perhaps) removing the code later. The userspace irqbalance daemon 
written by Arjan van de Ven does a wonderful job and should be used instead.

Signed-off-by: Auke Kok <auke-jan.h.kok@...el.com>

---

  Kconfig |   15 +++++++++++----
  1 file changed, 11 insertions(+), 4 deletions(-)
---

View attachment "mark_CONFIG_IRQBALANCE_as_obsolete.patch" of type "text/x-patch" (1014 bytes)