All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@infradead.org>
Cc: 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 05:41:35 -0600	[thread overview]
Message-ID: <ff6be121-5753-fe5f-90dc-8703da656d53@kernel.dk> (raw)
In-Reply-To: <YYOjcuEExwJN1eiw@infradead.org>

On 11/4/21 3:10 AM, Christoph Hellwig wrote:
> On Wed, Nov 03, 2021 at 12:32:21PM -0600, Jens Axboe wrote:
>> Retain the old logic for the fops based submit, but for our internal
>> blk_mq_submit_bio(), move the queue entering logic into the core
>> function itself.
> 
> Can you explain the why?  I guess you want to skip the extra reference
> for the cached requests now that they already have one.  But please
> state that, and explain why it is a fix, as to me it just seems like
> another little optimization.

It's just pointless to grab double references, and counter productive
too.

>> We need to be a bit careful if going into the scheduler, as a scheduler
>> or queue mappings can arbitrarily change before we have entered the queue.
>> Have the bio scheduler mapping do that separately, it's a very cheap
>> operation compared to actually doing merging locking and lookups.
> 
> So just don't do the merges for cache requets and side step this
> extra bio_queue_enter for that case?

I'd be fine with that, but it's a bit of a chicken and egg situation as
we don't know. I guess we could move the plugged request check earlier,
and just bypass merging there. Though that makes it a special case
thing, and it's generally useful now. Not sure that would be a good
idea.

>> -	if (unlikely(bio_queue_enter(bio) != 0))
>> -		return;
>> -
>>  	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.

>> +static inline bool blk_mq_queue_enter(struct request_queue *q, struct bio *bio)
>> +{
>> +	if (!blk_try_enter_queue(q, false) && bio_queue_enter(bio))
>> +		return false;
>> +	return true;
>> +}
> 
> 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.

>>  	} 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?

-- 
Jens Axboe


  reply	other threads:[~2021-11-04 11:41 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 [this message]
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
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=ff6be121-5753-fe5f-90dc-8703da656d53@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --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.