Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754041AbYJZKGS (ORCPT ); Sun, 26 Oct 2008 06:06:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752056AbYJZKF6 (ORCPT ); Sun, 26 Oct 2008 06:05:58 -0400 Received: from genesysrack.ru ([195.178.208.66]:33024 "EHLO tservice.net.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751361AbYJZKF5 (ORCPT ); Sun, 26 Oct 2008 06:05:57 -0400 Date: Sun, 26 Oct 2008 13:05:55 +0300 From: Evgeniy Polyakov To: Andrew Morton Cc: Peter Zijlstra , Mike Galbraith , Jiri Kosina , David Miller , rjw@sisk.pl, Ingo Molnar , s0mbre@tservice.net.ru, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [tbench regression fixes]: digging out smelly deadmen. Message-ID: <20081026100555.GA26033@ioremap.net> References: <20081024.221653.23695396.davem@davemloft.net> <1224914333.3822.18.camel@marge.simson.net> <1224917623.4929.15.camel@marge.simson.net> <20081025.002420.82739316.davem@davemloft.net> <1225010790.8566.22.camel@marge.simson.net> <1225011648.27415.4.camel@twins> <20081026021153.47878580.akpm@linux-foundation.org> <20081026092722.GA24799@ioremap.net> <20081026023439.c6cf4e94.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081026023439.c6cf4e94.akpm@linux-foundation.org> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1412 Lines: 29 Hi Andrew. On Sun, Oct 26, 2008 at 02:34:39AM -0700, Andrew Morton (akpm@linux-foundation.org) wrote: > Not necessarily. There are times when we have made changes which we > knew full well reduced dbench's throughput, because we believed them to > be of overall benefit. I referred to one of them above. I suppose, there were words about dbench is not a real-life test, so if it will suddenly suck, no one will care. Sigh, theorists... I'm not surprised there were no changes when I reported hrtimers to be the main guilty factor in my setup for dbench tests, and only when David showed that they also killed his sparks via wake_up(), something was done. Now this regression even dissapeared from the list. Good direction, we should always follow this. As a side note, is hrtimer subsystem also used for BH backend? I have not yet analyzed data about vanilla kernels only being able to accept clients at 20-30k accepts per second, while some other magical tree (not vanilla) around 2.6.18 was able to that with 50k accepts per second. There are lots of CPUs, ram, bandwidth, which are effectively unused even behind linux load balancer... -- Evgeniy Polyakov -- 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/