Messages in this thread | | | Date | Fri, 11 Jun 2004 18:58:13 +0200 | From | Jens Axboe <> | Subject | Re: 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/
| |