From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: barriers vs. reads Date: Wed, 23 Jun 2004 08:27:49 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040623062748.GC920@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> <20040622205748.GD3200@suse.de> <20040622201027.J1325@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]:43989 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S266055AbUFWG14 (ORCPT ); Wed, 23 Jun 2004 02:27:56 -0400 To: Werner Almesberger Content-Disposition: inline In-Reply-To: <20040622201027.J1325@almesberger.net> List-Id: linux-fsdevel.vger.kernel.org On Tue, Jun 22 2004, Werner Almesberger wrote: > Jens Axboe wrote: > > Overlapping requests are only detected if they start at the same > > sector. > > > > The mechanism is just there because of the data structure use, [...] > > So even the special handling of requests that start with the > same sector isn't required, and shouldn't be depended on, right ? Correct, it's just a side effect of the rbtree. 2.4 never tried to do anything about it. > > 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. > I see your point. Sounds like you have to be careful with request allocations once a single request suddenly needs 2 more request slots due to splitting (livelock country). -- Jens Axboe