lkml.org 
[lkml]   [2004]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: bug in md write barrier support?
On Wed, Sep 08 2004, Alan Cox wrote:
> On Mer, 2004-09-08 at 16:46, Jens Axboe wrote:
> > That's a worry if it really does that - does it, or are you just
> > speculating about possible problems?
>
> I2O defines cache flush very losely. It flushes the cache and returns
> when the cache has been flushed. From playing with the controllers I
> have it seems some at least merge further queued writes into the output
> stream. Thus if I issue
>
> write 1, 2, 3, 4 , 40, 41, flush cache, write 5, 6, 100
>
> it'll write 1,2,3,4,5,6, 40, 41, report flush cache complete.
>
> Obviously I can implement full barrier semantics in the driver if need
> be but that would cost performance hence the question.

Precisely, it's always possible to just drop queueing depth to zero at
that point. If I2O really does reorder around the cache flush (this
seems broken...), then you probably should.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.073 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site