Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751690AbYJ0ORj (ORCPT ); Mon, 27 Oct 2008 10:17:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750799AbYJ0OR1 (ORCPT ); Mon, 27 Oct 2008 10:17:27 -0400 Received: from mail.gmx.net ([213.165.64.20]:43334 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750779AbYJ0OR0 (ORCPT ); Mon, 27 Oct 2008 10:17:26 -0400 X-Authenticated: #14349625 X-Provags-ID: V01U2FsdGVkX1+j9KB845qj3NQwiRwUMsf8pg0ZeU8zp7M6apoyN0 3v6I3bNMnKqekk Subject: Re: [tbench regression fixes]: digging out smelly deadmen. From: Mike Galbraith To: Jiri Kosina Cc: Alan Cox , Ingo Molnar , Andrew Morton , Peter Zijlstra , David Miller , rjw@sisk.pl, s0mbre@tservice.net.ru, linux-kernel@vger.kernel.org, netdev@vger.kernel.org In-Reply-To: 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> <20081027112750.GA2771@elte.hu> <20081027113306.5b1d5898@lxorguk.ukuu.org.uk> <1225109171.4238.23.camel@marge.simson.net> Content-Type: text/plain Date: Mon, 27 Oct 2008 15:17:16 +0100 Message-Id: <1225117036.4973.23.camel@marge.simson.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1550 Lines: 32 On Mon, 2008-10-27 at 14:42 +0100, Jiri Kosina wrote: > On Mon, 27 Oct 2008, Mike Galbraith wrote: > > > > real world workloads. If your fairness hurts throughput that much maybe > > > your scheduler algorithm is just plain *wrong* as it isn't adapting to > > > workload at all well. > > Doesn't seem to be scheduler/fairness. 2.6.22.19 is O(1), and falls > > apart too, I posted the numbers and full dbench output yesterday. > > We'll need to look into this a little bit more I think. I have sent out > some numbers too, and these indicate very clearly that there is more than > 50% performance drop (measured by dbench) just after the very merge of CFS > in 2.6.23-rc1 merge window. Sure. Watching the per/sec output, every kernel I have sucks at high client count dbench, it's just a matter of how badly, and how long. BTW, the nice pretty 160 client numbers I posted yesterday for ext2 turned out to be because somebody adds _netdev mount option when I mount -a in order to mount my freshly hotplugged external drive (why? that ain't in my fstab). Without that switch, ext2 output is roughly as raggedy as ext3, and nowhere near the up to 1.4GB/sec I can get with dirty_ratio=50 + ext2 + (buy none, get one free) _netdev option. Free for the not asking option does nada for ext3. -Mike -- 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/