Re: barriers vs. reads

[Jens Axboe <axboe@suse.de>]

On Tue, Jun 22 2004, Werner Almesberger wrote:
> Jens Axboe wrote:
> > I don't think a read-barrier currently has a meaning. A write barrier
> > will force ordering for later reads too, of course.
> 
> That's one of the problem spots with priorities: if there are a
> lot of writes in the queue, high-priority reads will be delayed
> for a long time.

If there are lots of barrier writes, you mean?

> But do we have cases where reads must not cross write barriers ?

To me, it's the expected behaviour. If you issue a barrier write, a read
issued later should not be able to fetch old data.

> > It can't, the insert position doesn't tell you whether it's a barrier or
> > not. You have to check ->flags for that.
> 
> Yet deadline, AS, and CFQ don't do any such check :-)

Hmm? Recently this was moved into __elv_add_request() to make sure that
a barrier always implies ELEVATOR_INSERT_BACK so these checks were
removed. deadline still has it though:

        /* barriers must flush the reorder queue */
        if (unlikely(rq->flags & (REQ_SOFTBARRIER | REQ_HARDBARRIER)
                        && where == ELEVATOR_INSERT_SORT))
                where = ELEVATOR_INSERT_BACK;

this can be removed now, though. So it's definitely there, if you are
using a recent kernel you can assume that INSERT_BACK implies a barrier.

-- 
Jens Axboe