Linux block layer
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: xiakaixu <xiakaixu@huawei.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-block@vger.kernel.org, dchinner@redhat.com,
	sedat.dilek@gmail.com, Huxinwei <huxinwei@huawei.com>,
	"miaoxie (A)" <miaoxie@huawei.com>,
	Bintian <bintian.wang@huawei.com>
Subject: Re: [PATCHSET v5] Make background writeback great again for the first time
Date: Thu, 28 Apr 2016 12:36:45 -0600	[thread overview]
Message-ID: <5722583D.6080300@kernel.dk> (raw)
In-Reply-To: <57218C5B.2070308@huawei.com>

On 04/27/2016 10:06 PM, xiakaixu wrote:
>> diff --git a/lib/wbt.c b/lib/wbt.c
>> index 650da911f24f..322f5e04e994 100644
>> --- a/lib/wbt.c
>> +++ b/lib/wbt.c
>> @@ -98,18 +98,23 @@ void __wbt_done(struct rq_wb *rwb)
>>   	else
>>   		limit = rwb->wb_normal;
> Hi Jens,
>
> This statement 'limit = rwb->wb_normal' is executed twice, maybe once is
> enough. It is not a big deal anyway :)

I'll clean that up, thanks for noticing. No functional difference.

> Another question about this if branch:
>
>     if (rwb->wc && !atomic_read(&rwb->bdi->wb.dirty_sleeping))
> 	limit = 0;
>
> I can't follow the logic of this if branch. why set limit equal to 0
> when the device supports write back caches and there are tasks being
> limited in balance_dirty_pages(). Could you pelase give more info
> about this ?  Thanks!

Sure. So for write back caching, we have to try a bit harder to ensure 
that the device doesn't build up long internal queues with a lot of 
dirty data in the cache. So for the case where we have write back 
caching AND we don't have anyone waiting for the IO, allow the queue 
depth to drain to zero before building it back up again.

Does that make sense?

>>
>> +	inflight = atomic_dec_return(&rwb->inflight);
>> +
>>   	/*
>> -	 * Don't wake anyone up if we are above the normal limit. If
>> -	 * throttling got disabled (limit == 0) with waiters, ensure
>> -	 * that we wake them up.
>> +	 * wbt got disabled with IO in flight. Wake up any potential
>> +	 * waiters, we don't have to do more than that.
>>   	 */
>> -	inflight = atomic_dec_return(&rwb->inflight);
>> -	if (limit && inflight >= limit) {
>> -		if (!rwb->wb_max)
>> -			wake_up_all(&rwb->wait);
>> +	if (!rwb_enabled(rwb)) {
>> +		wake_up_all(&rwb->wait);
>>   		return;
>>   	}
>
> Maybe it is better that executing this if branch earlier. So we can wake up
> potential waiters in time when wbt got disabled.

The !rwb_enabled() case will only happen if someone disabled wbt while 
we had tracked IO in flight. We have to it below the 
atomic_dec_return(), so we could reorder that to be at the front. 
Ideally we just want it out-of-line instead, as it's the unexpected 
slower path.

-- 
Jens Axboe

  reply	other threads:[~2016-04-28 18:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26 15:55 [PATCHSET v5] Make background writeback great again for the first time Jens Axboe
2016-04-27 18:01 ` Jan Kara
2016-04-27 18:17   ` Jens Axboe
2016-04-27 20:37     ` Jens Axboe
2016-04-27 20:59       ` Jens Axboe
2016-04-28  4:06         ` xiakaixu
2016-04-28 18:36           ` Jens Axboe [this message]
2016-04-28 11:54         ` Jan Kara
2016-04-28 18:46           ` Jens Axboe
2016-05-03 12:17             ` Jan Kara
2016-05-03 12:40               ` Chris Mason
2016-05-03 13:06                 ` Jan Kara
2016-05-03 13:42                   ` Chris Mason
2016-05-03 13:57                     ` Jan Kara
2016-05-11 16:36               ` Jan Kara
2016-05-13 18:29                 ` Jens Axboe
2016-05-16  7:47                   ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5722583D.6080300@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=bintian.wang@huawei.com \
    --cc=dchinner@redhat.com \
    --cc=huxinwei@huawei.com \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miaoxie@huawei.com \
    --cc=sedat.dilek@gmail.com \
    --cc=xiakaixu@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox