tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal: B_ARRIER (addresses wapbl performance?)



On Wed, Oct 29, 2008 at 10:31:05PM -0400, Thor Lancelot Simon wrote:
> On Wed, Oct 29, 2008 at 08:57:16PM -0500, David Young wrote:
> > On Wed, Oct 29, 2008 at 05:51:09PM -0400, Thor Lancelot Simon wrote:
> > > I'd like to propose a new buffer flag, B_ARRIER.  This flag would be
> > > defined to cause a write barrier at whatever I/O request carries it.
> > 
> > Thor,
> > 
> > I have two questions about this.
> > 
> > How can a disk driver re-order B_BARRIER blocks with respect to other
> > blocks on its queue?  I.e., can a driver ever postpone writing a B_BARRIER
> > block until after it writes some !B_BARRIER blocks?
> 
> The answer has to be "if they were submitted first, sure" -- doesn't
> it?  In practice, I think disksort has to partition its sort (of
> writes, at least) by these bufs.  I am not entirely sure how to do
> that, unless the sort algorithm is "fifo".

Let us say that a disk driver has this list of blocks to write on its
queue, where the numbers indicate the physical block number, and [b]
indicates the presence of the B_BARRIER flag:

1, 5, 4, 3, 2, 9, 0 [b], 6, 8, 7, 9, 10 [b], 11, 13, 12, 14 [b]

then I may postpone writing the barrier blocks to the end, without
violating barrier semantics, right?  I may also arbitrarily re-order
the non-barrier blocks.  Here is the new order:

1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 0 [b], 10 [b], 14 [b]

However, if I have this list of blocks to write:

1, 2, 3, 4 (b), 1, 2, 3 (b), 1, 2 (b), 1 (b)

then I may re-order the non-barrier blocks between barrier blocks,
but the barrier blocks may not move:

3, 2, 1, 4 (b), 2, 1, 3 (b), 1, 2 (b), 1 (b)

> It can enqueue more !B_BARRIER blocks after a B_BARRIER block, too; the
> point is to tell the disk there is a barrier there (even if some disks
> are so stupid you have to implement this by completion waiting).

Hmm.  It seems that I may have misunderstood, or else there was some
unspoken condition on the barrier blocks.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24


Home | Main Index | Thread Index | Old Index