Date: Tue, 22 Mar 2016 14:30:00 -0700
From: Shaohua Li <shli@kernel.org>
To: Jens Axboe <axboe@fb.com>
Cc: Jeff Moyer <jmoyer@redhat.com>, linux-kernel@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH 6/6] writeback: throttle buffered writeback
Message-ID: <20160322213000.GA45596@kernel.org>
References: <1458669320-6819-1-git-send-email-axboe@fb.com>
 <1458669320-6819-7-git-send-email-axboe@fb.com>
 <x49twjyb7cb.fsf@segfault.boston.devel.redhat.com>
 <56F1A8D0.4060403@fb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56F1A8D0.4060403@fb.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 974
Lines: 25

On Tue, Mar 22, 2016 at 02:19:28PM -0600, Jens Axboe wrote:
> On 03/22/2016 02:12 PM, Jeff Moyer wrote:
> >Hi, Jens,
> >
> >Jens Axboe <axboe@fb.com> writes:
> >
> >>If the device has write back caching, 'wb_cache_delay' delays by
> >>this amount of usecs when a write completes before allowing more.
> >
> >What's the reason behind that?
> 
> For classic write back caching, the cache can absorb a bunch of writes
> shortly, which means that the completion cost only shows a small part of the
> overall cost. This means that if we just throttle on completion, then when
> the device starts committing to media, then we'll end up starving other IO
> anyway. This knob is a way to attempt to tame that.

Does request size matter? I think it's yes. If request size will be accounted,
there will be issue how to evaluate IO cost of each request, which is hard.

Looks the throttling is done regardless if there is other IO running, which
could hurt writeback.

Thanks,
Shaohua