From davem@redhat.com Tue May 20 17:10:29 2003 Path: post-office.corp.redhat.com!not-for-mail From: "David S. Miller" Newsgroups: rhat.general.linux-kernel Subject: Re: userspace irq balancer Date: Mon, 19 May 2003 23:13:19 -0700 (PDT) Organization: Red Hat Inc. Internal News Lines: 35 Message-ID: References: <20030520034622.GK8978@holomorphy.com> <1053407030.13207.253.camel@nighthawk> <88560000.1053409990@[10.10.2.4]> NNTP-Posting-Host: post-office.corp.redhat.com Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <88560000.1053409990@[10.10.2.4]> Xref: post-office.corp.redhat.com rhat.general.linux-kernel:77755 From: "Martin J. Bligh" Date: Mon, 19 May 2003 22:53:11 -0700 I have no frigging idea why you'd want to tear something out that works well already, and has a shitload of work put into it. It's pretty fundamentally broken for having had so much work put into it. Show me something other than "SpecWEB run for IBM ran faster" as a reason for keeping this code in there. Can you even do this? It is crap, from the very beginning, would you like to know why? How does the in-kernel IRQ load balancing measure "load" and "busyness"? Herein lies the most absolutely fundamental problem with this code, it fails to recognize that we end up with most of our networking "load" from softint context. We can process thousands of packets for one hardware interrupt. Are you able to comprehend this? Measuring hardware interrupts in some was as "load" is about as far from the truth as you can get. This is just the tip of the iceberg. rm -rf in-kernel-irqbalance; And hey, if _YOU_ want a broken system which uses this bogus algorithm, YOU CAN DO THIS with the userland thing if you want. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From akpm@digeo.com Tue May 20 17:21:26 2003 Path: post-office.corp.redhat.com!not-for-mail From: Andrew Morton Newsgroups: rhat.general.linux-kernel Subject: Re: userspace irq balancer Date: Tue, 20 May 2003 02:17:12 -0700 Organization: Red Hat Inc. Internal News Lines: 34 Message-ID: References: <200305191314.06216.pbadari@us.ibm.com> <1053382055.5959.346.camel@nighthawk> <20030519221111.P7061@devserv.devel.redhat.com> <1053382943.4827.358.camel@nighthawk> <1053401130.6830.3.camel@rth.ninka.net> <20030520034622.GK8978@holomorphy.com> <1053407030.13207.253.camel@nighthawk> <20030520090017.D17268@devserv.devel.redhat.com> NNTP-Posting-Host: post-office.corp.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Tue, 20 May 2003 09:19:00 +0000 (UTC) In-Reply-To: <20030520090017.D17268@devserv.devel.redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Xref: post-office.corp.redhat.com rhat.general.linux-kernel:77781 Arjan van de Ven wrote: > > On Mon, May 19, 2003 at 10:03:50PM -0700, Dave Hansen wrote: > > Does anyone have a patch to tear it out already? Is the current proc > > interface acceptable, or do we want a syscall interface like wli > > suggests? > > I have no problems with the proc interface; it's ascii so reasonably > extendible in the future for, say, when 64 cpus on > 32 bit linux get supported. It's also not THAT inefficient since my code > only uses it when some binding changes, not all the time. Concerns have been expressed that the /proc interface may be a bit racy. One thing we do need to do is to write a /proc stresstest tool which pokes numbers into the /proc files at high rates, run that under traffic for a few hours. There is no need to pull out the existing balancer until the userspace solution is proven - it can be turned off with `noirqbalance' until that work has been performed. Nobody has tried improving the current balancer. From a quick look it appears that it could work reasonably for the problematic packet-forwarding workload if the when-to-start-balancing threshold is reduced from 1000/sec to (say) 10/sec. Don't know - I've never seen a description of how the algorithm should be improved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/