Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 9 Feb 2003 23:48:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 9 Feb 2003 23:48:50 -0500 Received: from dial-ctb0186.webone.com.au ([210.9.241.86]:53252 "EHLO chimp.local.net") by vger.kernel.org with ESMTP id ; Sun, 9 Feb 2003 23:48:49 -0500 Message-ID: <3E473172.3060407@cyberone.com.au> Date: Mon, 10 Feb 2003 15:58:26 +1100 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 MIME-Version: 1.0 To: Jakob Oestergaard CC: Andrew Morton , David Lang , riel@conectiva.com.br, andrea@suse.de, ckolivas@yahoo.com.au, linux-kernel@vger.kernel.org, axboe@suse.de Subject: Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest] References:

<20030209203343.06608eb3.akpm@digeo.com> <20030210045107.GD1109@unthought.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1574 Lines: 42 Jakob Oestergaard wrote: >On Sun, Feb 09, 2003 at 08:33:43PM -0800, Andrew Morton wrote: > >>David Lang wrote: >> >>>note that issuing a fsync should change all pending writes to 'syncronous' >>>as should writes to any partition mounted with the sync option, or writes >>>to a directory with the S flag set. >>> >>We know, at I/O submission time, whether a write is to be waited upon. >>That's in writeback_control.sync_mode. >> >>That, combined with an assumption that "all reads are synchronous" would >>allow the outgoing BIOs to be appropriately tagged. >> > >This may be a terribly stupid question, if so pls. just tell me :) > >I assume read-ahead requests go elsewhere? Or do we assume that someone >is waiting for them as well? > >If we assume they are synchronous, that would be rather unfair >especially on multi-user systems - and the 90% accuracy that Rik >suggested would seem exaggerated to say the least (accuracy would be >more like 10% on a good day). > Remember that readahead gets scaled down quickly if it isn't getting hits. It is also likely to be sequential and in the track buffer, so it is a small cost. Huge readahead is a problem however anticipatory scheduling will hopefully allow good throughput for multiple read streams without requiring much readahead. Nick - 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/