Messages in this thread | | | Date | Fri, 11 Jun 2004 10:52:24 -0600 | From | "Eric D. Mudama" <> | Subject | Re: flush cache range proposal (was Re: ide errors in 7-rc1-mm1 and later) |
| |
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.
The barrier operation is basically a queueing-friendly flush+FUA, which may be better... it lets the driver keep the queue in the drive 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.
--eric
-- Eric D. Mudama edmudama@mail.bounceswoosh.org
- 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/
| |