From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: barriers vs. reads Date: Wed, 23 Jun 2004 01:14:04 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040623001404.GA28315@mail.shareable.org> 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> <20040622205748.GD3200@suse.de> <20040622201027.J1325@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jens Axboe , linux-fsdevel@vger.kernel.org Return-path: Received: from mail.shareable.org ([81.29.64.88]:28585 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S264958AbUFWAOS (ORCPT ); Tue, 22 Jun 2004 20:14:18 -0400 To: Werner Almesberger Content-Disposition: inline In-Reply-To: <20040622201027.J1325@almesberger.net> List-Id: linux-fsdevel.vger.kernel.org Werner Almesberger wrote: > > 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. > > The issue is that you may get large requests, in the middle of > which a single page gets a higher priority, e.g. because the > large request comes from a low-priority copy operation, and > there's a high-priority reader concurrently working on the > same file. > > In this case, the high-priority reader either has to wait for > the whole low-priority request to crawl to the head of the queue > (probably missing the deadline of the high-priority read), or we > could take the request and raise its priority, giving our > low-priority reader a nice boost. The latter isn't so bad if it > happens every once in a while, but someone may figure out how to > do this repeatedly, throwing off our bandwidth calculations. That's fine for a device with fast data transfer and slow seek times. But for a device with slow data transfer (e.g. nbd to a remote disk), you'd want to split the request for sure. -- Jamie