Re: barriers vs. reads

[Jens Axboe <axboe@suse.de>]

On Tue, Jun 22 2004, Werner Almesberger wrote:
> Jens Axboe wrote:
> > If there are lots of barrier writes, you mean?
> 
> If there are a lot of writes before the barrier. Then the reads
> after the barrier have to wait for all these writes to complete.
> Of course, things get even worse if you have a lot of barriers,
> in addition to there being lots of writes.

There's nothing you can do about that, in my opinion. Barriers are bad
for io scheduler performance, that's a given.

> > 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.
> 
> ... which pretty much kills the idea of short predictable
> queuing delays :-(

So you can't support guarenteed low delays with lots of writes and
barriers, big deal. If you need hard guarantees, you need to tailor the
environment. IMHO this is no different than the regular linux code base
not supporting hard realtime processing.

> > Hmm? Recently this was moved into __elv_add_request()
> 
> Ah, okay, different definition of where the elevator starts ;-)
> Yes, I saw that.
> 
> BTW, in what cases would ELEVATOR_INSERT_FRONT combined with
> a barrier make sense ?

It wouldn't really, INSERT_BACK is the only one that really makes sense.
But if you do an elv_requeue_request() (ide barrier does this) to
reinsert a barrier, it would have the barrier bit set but need to go to
the front anyways. SCSI does it too, come to think of it.

-- 
Jens Axboe