Re: barriers vs. reads

[Jens Axboe <axboe@suse.de>]

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