Re: Reworking dm-writeboost [was: Re: staging: Add dm-writeboost]

[Mike Snitzer <snitzer@redhat.com>]

On Tue, Oct 08 2013 at  6:37am -0400,
Akira Hayakawa <ruby.wktk@gmail.com> wrote:

> Christoph,
> 
> > You can detect O_DIRECT writes by second guession a special combination
> > of REQ_ flags only used there, as cfg tries to treat it special:
> > 
> > #define WRITE_SYNC              (WRITE | REQ_SYNC | REQ_NOIDLE)
> > #define WRITE_ODIRECT           (WRITE | REQ_SYNC)
> > 
> > the lack of REQ_NOIDLE when REQ_SYNC is set gives it away.  Not related
> > to the FLUSH or FUA flags in any way, though.
> Thanks.
> But, our problem is to detect the bio may or may not be deferred.
> The flag REQ_NOIDLE is the one?
> 
> > Akira, can you explain the workloads where your delay of FLUSH or FUA
> > requests helps you in any way?  I very much agree with Dave's reasoning,
> > but if you found workloads where your hack helps we should make sure we
> > fix them at the place where they are issued.
> One of the examples is a fileserver accessed by multiple users.
> A barrier is submitted when a user closes a file for example.
> 
> As I said in my previous post
> https://lkml.org/lkml/2013/10/4/186
> writeboost has RAM buffer and we want one to be
> fulfilled with writes and then flushed to the cache device
> that takes all the barriers away with the completion.
> In that case we pay the minimum penalty for the barriers.
> Interestingly, writeboost is happy with a lot of writes.
> 
> By deferring these barriers (FLUSH and FUA)
> multiple barriers are likely to be merged on a RAM buffer
> and then processed by replacing with only one FLUSH.
> 
> Merging the barriers and replacing it with a single FLUSH
> by accepting a lot of writes
> is the reason for deferring barriers in writeboost.
> If you want to know further I recommend you to
> look at the source code to see
> how queue_barrier_io() is used and
> how the barriers are kidnapped in queue_flushing().

AFAICT, this is an unfortunate hack resulting from dm-writeboost being a
bio-based DM target.  The block layer already has support for FLUSH
merging, see commit ae1b1539622fb4 ("block: reimplement FLUSH/FUA to
support merge")