Re: barriers vs. reads

[Jamie Lokier <jamie@shareable.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