lkml.org 
[lkml]   [2004]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: flush cache range proposal (was Re: ide errors in 7-rc1-mm1 and later)
On Fri, Jun 11 2004, Eric D. Mudama wrote:
> On Fri, Jun 11 at 12:31, Jeff Garzik wrote:
> >If queued-FUA is out of the question, this seems quite reasonable. It
> >appears to achieve the commit-block semantics described for barrier
> >operation, AFAICS.
>
> Queued FUA shouldn't be out of the question.
>
> However, Queued FUA requires waiting for the queue to drain before
> sending more commands, since a pair of queued FUA commands doesn't
> guarantee the ordering of those two commands, which may or may not be
> acceptable semantics.

You can continue building and reordering requests behind the QUEUED_FUA
write(s).

> The barrier operation is basically a queueing-friendly flush+FUA,
> which may be better... it lets the driver keep the queue in the drive

That's exactly correct.

> full, and also allows writes other than the commit block to not be
> done as FUA operations, which is potentially faster. THe bigger the
> ratio of data to commit block, the better the performance would be
> with a barrier operation vs a purely queued FUA workload.

Just looking at how pre/write/post flush performs and I don't think it
will be that bad (it's already quite good). Depends on how sync
intensive the workload is of course.

But as long as it's the fastest possible implementation (and I think it
is), then arguing about performance is futile imo. Correctness comes
first.

--
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:03    [W:0.705 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site