All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>, linux-block@vger.kernel.org
Subject: Re: [PATCH 3/4] block: move queue enter logic into blk_mq_submit_bio()
Date: Thu, 4 Nov 2021 10:30:48 -0700	[thread overview]
Message-ID: <YYQYyEljsvANMP3q@infradead.org> (raw)
In-Reply-To: <ff6be121-5753-fe5f-90dc-8703da656d53@kernel.dk>

On Thu, Nov 04, 2021 at 05:41:35AM -0600, Jens Axboe wrote:
> >>  	if (!submit_bio_checks(bio) || !blk_crypto_bio_prep(&bio))
> >> -		goto queue_exit;
> >> +		return;
> > 
> > This is broken, we really ant the submit checks under freeze
> > protection to make sure the parameters can't be changed underneath
> > us.
> 
> Which parameters are you worried about in submit_bio_checks()? I don't
> immediately see anything that would make me worry about it.

Mostly checks if certain operations are supported or not, as
revalidation could clear those.

> > This looks weird, as blk_try_enter_queue is already called by
> > bio_queue_enter.
> 
> It's just for avoiding a pointless call into bio_queue_enter(), which
> isn't needed it blk_try_enter_queue() is successful. The latter is short
> and small and can be inlined, while bio_queue_enter() is a lot bigger.

If this is so impotant let's operated with an inlined bio_queue_enter
that calls out of line into slow path instead of open coding it
like this.

> >>  	} else {
> >>  		struct blk_mq_alloc_data data = {
> >>  			.q		= q,
> >> @@ -2528,6 +2534,11 @@ void blk_mq_submit_bio(struct bio *bio)
> >>  			.cmd_flags	= bio->bi_opf,
> >>  		};
> >>  
> >> +		if (unlikely(!blk_mq_queue_enter(q, bio)))
> >> +			return;
> >> +
> >> +		rq_qos_throttle(q, bio);
> >> +
> > 
> > At some point the code in this !cached branch really needs to move
> > into a helper..
> 
> Like in the next patch?

No, I mean the !cached case which is a lot more convoluted.

  parent reply	other threads:[~2021-11-04 17:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 18:32 [PATCHSET 0/4] Alloc batch fixes Jens Axboe
2021-11-03 18:32 ` [PATCH 1/4] block: have plug stored requests hold references to the queue Jens Axboe
2021-11-04  9:01   ` Christoph Hellwig
2021-11-04 11:33     ` Jens Axboe
2021-11-03 18:32 ` [PATCH 2/4] block: make blk_try_enter_queue() available for blk-mq Jens Axboe
2021-11-03 18:32 ` [PATCH 3/4] block: move queue enter logic into blk_mq_submit_bio() Jens Axboe
2021-11-04  9:10   ` Christoph Hellwig
2021-11-04 11:41     ` Jens Axboe
2021-11-04 12:14       ` Jens Axboe
2021-11-04 17:32         ` Christoph Hellwig
2021-11-04 17:35           ` Jens Axboe
2021-11-04 17:30       ` Christoph Hellwig [this message]
2021-11-04 17:36         ` Jens Axboe
2021-11-03 18:32 ` [PATCH 4/4] block: move plug rq alloc into helper and ensure queue match Jens Axboe
2021-11-04  9:17   ` Christoph Hellwig
2021-11-04 11:35     ` Jens Axboe
2021-11-04 17:33       ` Christoph Hellwig
2021-11-04 17:37         ` 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=YYQYyEljsvANMP3q@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.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.