Re: barriers vs. reads

[Werner Almesberger <wa@almesberger.net>]

Jamie Lokier wrote:
> This whole thread is asking a simple question: what shall we define
> "I/O write barrier" to mean?  Does it force an ordering for reads
> after the barrier which overlap writes before the barrier, or not?

It's always the simple questions that are the hardest to answer ;-)

So far, we seem to have the following rules (at least for
"barrier-only" barriers. Special requests come with their own
barriers, see below):

 i) write requests may never cross a barrier that separates
    them from other write requests
 ii) a read request R and a write request W may change their
     order (with respect to each other), unless they overlap
     AND are separated by at least one barrier
 iii) in all other cases, requests are free to move about

Rule ii) seems a little tricky. Is there actually a means for
user space to send a barrier, e.g. when doing direct IO ? If
not, the I think only user of ii) would be "direct IO" that
comes from unbuffered file system meta-data and such.

> Or even to define two kinds of barrier, if that would be useful.

I can think of three distinct uses of barriers (but there may
be more):

 1) ensure integrity involving multiple requests
 2) disentangle overlapping requests
 3) make sure special requests (power management or such) don't
    wander off

2) may merit a distinction. E.g. an elevator that automatically
puts overlapping requests in FIFO order (i.e. Bryan's "ideal"
elevator) could ignore this kind of barriers. Barriers of type
3) restricts the move of anything.

Cheers, Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/