Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Feb 2003 02:25:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Feb 2003 02:25:30 -0500 Received: from [195.223.140.107] ([195.223.140.107]:46209 "EHLO athlon.random") by vger.kernel.org with ESMTP id ; Mon, 10 Feb 2003 02:25:27 -0500 Date: Mon, 10 Feb 2003 08:34:58 +0100 From: Andrea Arcangeli To: Jakob Oestergaard , Andrew Morton , David Lang , riel@conectiva.com.br, 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] Message-ID: <20030210073458.GI31401@dualathlon.random> References:

<20030209203343.06608eb3.akpm@digeo.com> <20030210045107.GD1109@unthought.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030210045107.GD1109@unthought.net> User-Agent: Mutt/1.4i X-GPG-Key: 1024D/68B9CB43 X-PGP-Key: 1024R/CB4660B9 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1637 Lines: 36 On Mon, Feb 10, 2003 at 05:51:07AM +0100, 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? readahead is meant for merging. So in short normally there is no additional request generated by readhaead. Inter-process merging must not be forbidden by SFQ. We also have to choose if to forbid or not outer-process merging. In theory SFQ would tell us to avoid it, and to only merge in the context of the same pid, in the common case it should just take care of most merging, things like dbench aren't going to run well with SFQ no matter if we do global merging or only per-process merging. Optimizing for throughput is not the object here. Andrea - 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/