From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756903AbZJBS0H (ORCPT ); Fri, 2 Oct 2009 14:26:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754265AbZJBS0G (ORCPT ); Fri, 2 Oct 2009 14:26:06 -0400 Received: from brick.kernel.dk ([93.163.65.50]:54661 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750844AbZJBS0F (ORCPT ); Fri, 2 Oct 2009 14:26:05 -0400 Date: Fri, 2 Oct 2009 20:26:08 +0200 From: Jens Axboe To: Mike Galbraith Cc: Ingo Molnar , Linus Torvalds , Vivek Goyal , Ulrich Lukas , linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, dm-devel@redhat.com, nauman@google.com, dpshah@google.com, lizf@cn.fujitsu.com, mikew@google.com, fchecconi@gmail.com, paolo.valente@unimore.it, ryov@valinux.co.jp, fernando@oss.ntt.co.jp, jmoyer@redhat.com, dhaval@linux.vnet.ibm.com, balbir@linux.vnet.ibm.com, righi.andrea@gmail.com, m-ikeda@ds.jp.nec.com, agk@redhat.com, akpm@linux-foundation.org, peterz@infradead.org, jmarchan@redhat.com, riel@redhat.com Subject: Re: IO scheduler based IO controller V10 Message-ID: <20091002182608.GO31616@kernel.dk> References: <20091002145610.GD31616@kernel.dk> <20091002171129.GG31616@kernel.dk> <20091002172046.GA2376@elte.hu> <20091002172554.GJ31616@kernel.dk> <20091002172842.GA4884@elte.hu> <20091002173732.GK31616@kernel.dk> <20091002175629.GA14860@elte.hu> <20091002180437.GL31616@kernel.dk> <1254507754.8667.15.camel@marge.simson.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1254507754.8667.15.camel@marge.simson.net> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 02 2009, Mike Galbraith wrote: > On Fri, 2009-10-02 at 20:04 +0200, Jens Axboe wrote: > > > I'm not too crazy about it either. How about just using 'desktop' since > > this is obviously what we are really targetting? 'latency' isn't fully > > descriptive either, since it may not necessarily provide the best single > > IO latency (noop would). > > Grin. "Perfect is the enemy of good" :) > Avg > 16.24 175.82 154.38 228.97 147.16 144.5 noop > 43.23 57.39 96.13 148.25 180.09 105.0 deadline Yep, that's where it falls down. Noop basically fails here because it treats all IO as equal, which obviously isn't true for most people. But even for pure read workloads (is the above the mixed read/write, or just read?), latency would be excellent with noop but the desktop experience would not. -- Jens Axboe