[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110123102920.GB23121@htj.dyndns.org>
Date: Sun, 23 Jan 2011 11:29:20 +0100
From: Tejun Heo <tj@...nel.org>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: axboe@...nel.dk, tytso@....edu, djwong@...ibm.com, shli@...nel.org,
neilb@...e.de, adilger.kernel@...ger.ca, jack@...e.cz,
snitzer@...hat.com, linux-kernel@...r.kernel.org,
kmannth@...ibm.com, cmm@...ibm.com, linux-ext4@...r.kernel.org,
rwheeler@...hat.com, hch@....de, josef@...hat.com
Subject: Re: [PATCH 3/3] block: reimplement FLUSH/FUA to support merge
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists