From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: barriers vs. reads Date: Tue, 22 Jun 2004 22:57:49 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040622205748.GD3200@suse.de> References: <20040622005302.A1325@almesberger.net> <20040622073919.GV12881@suse.de> <20040622045004.C1325@almesberger.net> <20040622075531.GX12881@suse.de> <20040622112802.GA21456@mail.shareable.org> <20040622113245.GA1104@suse.de> <20040622155308.G1325@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jamie Lokier , linux-fsdevel@vger.kernel.org Return-path: Received: from ns.virtualhost.dk ([195.184.98.160]:49623 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S266007AbUFVU5y (ORCPT ); Tue, 22 Jun 2004 16:57:54 -0400 To: Werner Almesberger Content-Disposition: inline In-Reply-To: <20040622155308.G1325@almesberger.net> List-Id: linux-fsdevel.vger.kernel.org On Tue, Jun 22 2004, Werner Almesberger wrote: > Jens Axboe wrote: > > It can happen with direct io of any sort, the solution has to take this > > into account. That's why we currently have handling for rbtree aliases > > as well. > > How well is this actually supposed to work ? When reading what > as-iosched does, I was left with the impression that you could > construct a set of partially overlapping requests that doesn't > get sorted in FIFO order. Overlapping requests are only detected if they start at the same sector. The mechanism is just there because of the data structure use, Linux has never made any effort to guard against this outside of the page cache context. If you issue direct io that overlaps, you are providing your own rope. > I haven't tried to feed as-iosched such a request mix, though, > so maybe I'm wrong. > > (For partially overlapping requests, it may actually be nice > to be able to break them into multiple parts, and queue them > separately. Particularly if they also come with distinct > priorities.) Bad idea, unless you have zero setup overhead for the hardware issued commands. Linux will also attempt to remerge these requests when it later discovers they are adjacent. You can block this by disallowing merging of request with different priorities, but I really don't see why you'd want to do that. It would be a net loss in the end anyways. -- Jens Axboe