Thread (9 messages) 9 messages, 4 authors, 2011-03-23

Re: [PATCH 3/3] block: reimplement FLUSH/FUA to support merge

From: Tejun Heo <tj@kernel.org>
Date: 2011-01-23 10:29:27
Also in: lkml

Possibly related (same subject, not in this thread)

On Sun, Jan 23, 2011 at 11:25:26AM +0100, Tejun Heo wrote:
Again, issuing flushes as fast as possible isn't necessarily better.
It might feel counter-intuitive but it generally makes sense to delay
flush if there are a lot of concurrent flush activities going on.
Another related interesting point is that with flush merging,
depending on workload, there's a likelihood that FUA, even if the
device supports it, might result in worse performance than merged DATA
+ single POSTFLUSH sequence.
Let me add a bit.

In general, I'm a bit skeptical about the usefulness of hardware FUA
on a rotating disk.  All it saves is a single command issue overhead.
On storage array or SSDs, the balance might be different tho.  Event
hen, with flush merging, I think it would heavily depend on the
workload which way it would turn out.

Thanks.

-- 
tejun
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help