[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <34041F0A-F460-4736-9A6C-76D861EA0070@linaro.org>
Date: Thu, 8 Feb 2018 08:16:51 +0100
From: Paolo Valente <paolo.valente@...aro.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: linux-block <linux-block@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Mark Brown <broonie@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
'Paolo Valente' via bfq-iosched
<bfq-iosched@...glegroups.com>,
Oleksandr Natalenko <oleksandr@...alenko.name>,
Alban Browaeys <alban.browaeys@...il.com>,
Ming Lei <ming.lei@...hat.com>, Ivan Kozik <ivan@...ios.org>,
169364@...denti.unimore.it, holger@...lied-asynchrony.com,
efault@....de, Serena Ziviani <ziviani.serena@...il.com>
Subject: Re: [PATCH BUGFIX V3] block, bfq: add requeue-request hook
> Il giorno 07 feb 2018, alle ore 23:18, Jens Axboe <axboe@...nel.dk> ha scritto:
>
> On 2/7/18 2:19 PM, Paolo Valente wrote:
>> Commit 'a6a252e64914 ("blk-mq-sched: decide how to handle flush rq via
>> RQF_FLUSH_SEQ")' makes all non-flush re-prepared requests for a device
>> be re-inserted into the active I/O scheduler for that device. As a
>> consequence, I/O schedulers may get the same request inserted again,
>> even several times, without a finish_request invoked on that request
>> before each re-insertion.
>>
>> This fact is the cause of the failure reported in [1]. For an I/O
>> scheduler, every re-insertion of the same re-prepared request is
>> equivalent to the insertion of a new request. For schedulers like
>> mq-deadline or kyber, this fact causes no harm. In contrast, it
>> confuses a stateful scheduler like BFQ, which keeps state for an I/O
>> request, until the finish_request hook is invoked on the request. In
>> particular, BFQ may get stuck, waiting forever for the number of
>> request dispatches, of the same request, to be balanced by an equal
>> number of request completions (while there will be one completion for
>> that request). In this state, BFQ may refuse to serve I/O requests
>> from other bfq_queues. The hang reported in [1] then follows.
>>
>> However, the above re-prepared requests undergo a requeue, thus the
>> requeue_request hook of the active elevator is invoked for these
>> requests, if set. This commit then addresses the above issue by
>> properly implementing the hook requeue_request in BFQ.
>
> Thanks, applied.
>
I Jens,
I forgot to add
Tested-by: Oleksandr Natalenko <oleksandr@...alenko.name>
in the patch.
Is it still possible to add it?
Thanks,
Paolo
> --
> Jens Axboe
Powered by blists - more mailing lists