From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761622AbYDUUC3 (ORCPT ); Mon, 21 Apr 2008 16:02:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755875AbYDUUCQ (ORCPT ); Mon, 21 Apr 2008 16:02:16 -0400 Received: from g1t0029.austin.hp.com ([15.216.28.36]:30262 "EHLO g1t0029.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755283AbYDUUCQ (ORCPT ); Mon, 21 Apr 2008 16:02:16 -0400 Message-ID: <480CF2C0.9050208@hp.com> Date: Mon, 21 Apr 2008 13:02:08 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.7.13) Gecko/20060601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bodo Eggert <7eggert@gmx.de> CC: Kok@vger.kernel.org, Auke , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Linux Kernel Mailing List , Anton Titov , Chris Snook , "H. Willstrand" , netdev@vger.kernel.org, Jesse Brandeburg , Linus Torvalds , Andrew Morton Subject: Re: [PATCH] Re: Bad network performance over 2Gbps References: <480CC3D8.3040700@hp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bodo Eggert wrote: > On Mon, 21 Apr 2008, Rick Jones wrote: >>Be it kernel or user space, for consistent benchmark results it needs to be >>able to be turned-off without turning the code. That leaves me in agreement >>with Stephen that if it must exist, the user space one would be preferable. >>It can be easily terminated with extreme prejudice. > > > I agree that having a full-featured userspace balancer daemon with lots of > intelligence will be theoretically better, but if you can have a simple > daemon doing OK on many machines for less than the userspace daemon's > kernel stack, why not? Perhaps my judgement is too colored by benchmark(et)ing, and desires to have repeatable results on things like neperf, but I very much like to know where my interrupts are going and don't like them moving around. That is why I am not particularly fond of either flavor of irq balancing. That being the case, whatever is out there aught to be able to be disabled on a running system without having to roll bits or reboot. rick jones