All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	Paolo Valente <paolo.valente@linaro.org>,
	Ming Lei <ming.lei@redhat.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] Revert "mq-deadline: Fix request accounting"
Date: Tue, 7 Sep 2021 16:28:49 +0000	[thread overview]
Message-ID: <YTeTQGrw41k08hgf@x1-carbon> (raw)
In-Reply-To: <fdd5ab2a-af90-69bd-2d37-c5060ce68de4@acm.org>

On Tue, Sep 07, 2021 at 08:15:03AM -0700, Bart Van Assche wrote:
> On 9/7/21 7:21 AM, Niklas Cassel wrote:
> > blk-mq will no longer call the I/O scheduler .finish_request() callback
> > for requests that were never inserted to the I/O scheduler.
> 
> I do not agree. Even with patch 1/2 from this series applied, finish_request()
> will still be called for requests inserted by blk_insert_cloned_request()
> although these requests are never inserted to the I/O scheduler.
> 
> Bart.

Hello Bart,


Looking at blk_mq_free_request(),
e->type->ops.finish_request() will only be called if RQF_ELVPRIV
is set.

blk_insert_cloned_request() doesn't seem to allocate a request
itself, but instead takes an already cloned request.

So I guess it depends on how the supplied request was cloned.

I would assume if the original request doesn't have RQF_ELVPRIV set,
then neither will the cloned request?

I tried to look at blk_rq_prep_clone(), which seems to be a common
cloning function, but I don't see req->rq_flags being copied
(except for RQF_SPECIAL_PAYLOAD).

Anyway, I don't see how .finish_request() will be called in relation
to blk_insert_cloned_request(). Could you please help me out and
give me an example of a call chain where this can happen?


Kind regards,
Niklas

  reply	other threads:[~2021-09-07 16:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07 14:21 [PATCH 0/2] don't call io scheduler callbacks for passthrough requests Niklas Cassel
2021-09-07 14:21 ` [PATCH 1/2] blk-mq: don't call callbacks for requests that bypassed the scheduler Niklas Cassel
2021-09-07 14:29   ` Ming Lei
2021-09-07 14:21 ` [PATCH 2/2] Revert "mq-deadline: Fix request accounting" Niklas Cassel
2021-09-07 14:54   ` Bart Van Assche
2021-09-07 16:07     ` Niklas Cassel
2021-09-07 16:49       ` Bart Van Assche
2021-09-07 15:15   ` Bart Van Assche
2021-09-07 16:28     ` Niklas Cassel [this message]
2021-09-07 17:12       ` Bart Van Assche
2021-09-08 11:57         ` Niklas Cassel

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=YTeTQGrw41k08hgf@x1-carbon \
    --to=niklas.cassel@wdc.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=paolo.valente@linaro.org \
    /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.