From: Jens Axboe <axboe@kernel.dk>
To: Chengming Zhou <chengming.zhou@linux.dev>,
Bart Van Assche <bvanassche@acm.org>,
hch@lst.de
Cc: oe-lkp@lists.linux.dev, lkp@intel.com,
Chuck Lever <chuck.lever@oracle.com>,
linux-block@vger.kernel.org, cel@kernel.org,
linux-kernel@vger.kernel.org,
kernel test robot <oliver.sang@intel.com>
Subject: Re: [PATCH v2] blk-mq: release scheduler resource when request complete
Date: Thu, 17 Aug 2023 11:20:17 -0600 [thread overview]
Message-ID: <8c262b00-9856-49fa-b425-da863efdff7d@kernel.dk> (raw)
In-Reply-To: <317715dc-f6e4-1847-5b78-b2d8184b446a@linux.dev>
On 8/17/23 9:29 AM, Chengming Zhou wrote:
> On 2023/8/17 22:50, Bart Van Assche wrote:
>> On 8/17/23 07:41, kernel test robot wrote:
>>> [ 222.622837][ T2216] statistics for priority 1: i 276 m 0 d 276 c 278
>>> [ 222.629307][ T2216] WARNING: CPU: 0 PID: 2216 at block/mq-deadline.c:680 dd_exit_sched (block/mq-deadline.c:680 (discriminator 3))
>>
>> The above information shows that dd_inserted_request() has been called
>> 276 times and also that dd_finish_request() has been called 278 times.
>
> Thanks much for your help.
>
> This patch indeed introduced a regression, postflush requests will be completed
> twice, so here dd_finish_request() is more than dd_inserted_request().
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index a8c63bef8ff1..7cd47ffc04ce 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -686,8 +686,10 @@ static void blk_mq_finish_request(struct request *rq)
> {
> struct request_queue *q = rq->q;
>
> - if (rq->rq_flags & RQF_USE_SCHED)
> + if (rq->rq_flags & RQF_USE_SCHED) {
> q->elevator->type->ops.finish_request(rq);
> + rq->rq_flags &= ~RQF_USE_SCHED;
> + }
> }
>
>
> Clear RQF_USE_SCHED flag here should fix this problem, which should be ok
> since finish_request() is the last callback, this flag isn't needed anymore.
>
> Jens, should I send this diff as another patch or resend updated v3?
I don't think this is the right solution, it makes all kinds of
assumptions on what that flag is and when it's safe to clear it. It's a
very fragile fix, I think we need to do better than that.
--
Jens Axboe
next prev parent reply other threads:[~2023-08-17 17:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-13 15:23 [PATCH v2] blk-mq: release scheduler resource when request complete chengming.zhou
2023-08-13 15:34 ` Jens Axboe
2023-08-13 15:45 ` Chengming Zhou
2023-08-14 21:42 ` Jens Axboe
2023-08-17 14:41 ` kernel test robot
2023-08-17 14:50 ` Bart Van Assche
2023-08-17 15:29 ` Chengming Zhou
2023-08-17 17:17 ` Chengming Zhou
2023-08-17 17:26 ` Jens Axboe
2023-08-17 17:20 ` Jens Axboe [this message]
2023-08-17 17:24 ` Jens Axboe
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=8c262b00-9856-49fa-b425-da863efdff7d@kernel.dk \
--to=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=cel@kernel.org \
--cc=chengming.zhou@linux.dev \
--cc=chuck.lever@oracle.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.