Re: flush cache range proposal (was Re: ide errors in 7-rc1-mm1 and later)

[Eric D. Mudama]

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@xxxxxxxxxxxxxxxxxxxxx

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