From: Joseph Qi <jiangqi903@gmail.com>
To: Shaohua Li <shli@kernel.org>
Cc: linux-block <linux-block@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>, Shaohua Li <shli@fb.com>,
boyu.mt@taobao.com, wenqing.lz@taobao.com,
qijiang.qj@alibaba-inc.com
Subject: Re: [PATCH] blk-throttle: fix possible io stall when doing upgrade
Date: Tue, 26 Sep 2017 11:16:05 +0800 [thread overview]
Message-ID: <4881c35d-6dde-ba81-2771-798d5701c245@gmail.com> (raw)
In-Reply-To: <20170926024820.2kxmluua6abvno4j@kernel.org>
On 17/9/26 10:48, Shaohua Li wrote:
> On Tue, Sep 26, 2017 at 09:06:57AM +0800, Joseph Qi wrote:
>> Hi Shaohua,
>>
>> On 17/9/26 01:22, Shaohua Li wrote:
>>> On Mon, Sep 25, 2017 at 06:46:42PM +0800, Joseph Qi wrote:
>>>> From: Joseph Qi <qijiang.qj@alibaba-inc.com>
>>>>
>>>> Currently it will try to dispatch bio in throtl_upgrade_state. This may
>>>> lead to io stall in the following case.
>>>> Say the hierarchy is like:
>>>> /-test1
>>>> |-subtest1
>>>> and subtest1 has 32 queued bios now.
>>>>
>>>> throtl_pending_timer_fn throtl_upgrade_state
>>>> ------------------------------------------------------------------------
>>>> upgrade to max
>>>> throtl_select_dispatch
>>>> throtl_schedule_next_dispatch
>>>> throtl_select_dispatch
>>>> throtl_schedule_next_dispatch
>>>>
>>>> Since throtl_select_dispatch will move queued bios from subtest1 to
>>>> test1 in throtl_upgrade_state, it will then just do nothing in
>>>> throtl_pending_timer_fn. As a result, queued bios won't be dispatched
>>>> any more if no proper timer scheduled.
>>>
>>> Sorry, didn't get it. If throtl_pending_timer_fn does nothing (because
>>> throtl_upgrade_state already moves bios to parent), there is no pending
>>> blkcg/bio, not rearming the timer wouldn't lose anything. Am I missing
>>> anything? could you please describe the failure in details?
>>>
>>> Thanks,
>>> Shaohua
>>> In normal case, throtl_pending_timer_fn tries to move bios from
>> subtest1 to test1, and finally do the real issueing work when reach
>> the top-level.
>> But int the case above, throtl_select_dispatch in
>> throtl_pending_timer_fn returns 0, because the work is done by
>> throtl_upgrade_state. Then throtl_pending_timer_fn *thinks* there is
>> nothing to do, but the queued bios are still in service queue of
>> test1.
>
> Still didn't get, sorry. If there are pending bios in test1, why
> throtl_schedule_next_dispatch in throtl_pending_timer_fn doesn't setup the
> timer?
>
throtl_schedule_next_dispatch doesn't setup timer because there is no
pending children left, all the queued bios are moved to parent test1
now. IMO, this is used in case that it cannot dispatch all queued bios
in one round.
And if the select dispatch is done by timer, it will then do propagate
dispatch in parent till reach the top-level.
But in the case above, it breaks this logic.
Please point out if I am understanding wrong.
Thanks,
Joseph
next prev parent reply other threads:[~2017-09-26 3:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-25 10:46 [PATCH] blk-throttle: fix possible io stall when doing upgrade Joseph Qi
2017-09-25 17:22 ` Shaohua Li
2017-09-26 1:06 ` Joseph Qi
2017-09-26 2:48 ` Shaohua Li
2017-09-26 3:16 ` Joseph Qi [this message]
2017-09-27 21:38 ` Shaohua Li
2017-09-28 3:48 ` Joseph Qi
2017-09-28 11:19 ` Joseph Qi
2017-09-28 21:18 ` Shaohua Li
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=4881c35d-6dde-ba81-2771-798d5701c245@gmail.com \
--to=jiangqi903@gmail.com \
--cc=axboe@kernel.dk \
--cc=boyu.mt@taobao.com \
--cc=linux-block@vger.kernel.org \
--cc=qijiang.qj@alibaba-inc.com \
--cc=shli@fb.com \
--cc=shli@kernel.org \
--cc=wenqing.lz@taobao.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