public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: "jianchao.wang" <jianchao.w.wang@oracle.com>
To: Jens Axboe <axboe@kernel.dk>, Ming Lei <ming.lei@redhat.com>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] blk-mq: put the driver tag of nxt rq before first one is requeued
Date: Wed, 13 Sep 2017 11:39:16 +0800	[thread overview]
Message-ID: <aebfc622-6d7d-0d07-5a13-8dae06a49bb7@oracle.com> (raw)
In-Reply-To: <6327de01-0bf4-7e79-59ad-f6489378bfd5@kernel.dk>



On 09/13/2017 10:45 AM, Jens Axboe wrote:
>>>>>>>> @@ -1029,14 +1029,20 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list)
>>>>>>>>  		if (list_empty(list))
>>>>>>>>  			bd.last = true;
>>>>>>>>  		else {
>>>>>>>> -			struct request *nxt;
>>>>>>>> -
>>>>>>>>  			nxt = list_first_entry(list, struct request, queuelist);
>>>>>>>>  			bd.last = !blk_mq_get_driver_tag(nxt, NULL, false);
>>>>>>>>  		}
>>>>>>>>  
>>>>>>>>  		ret = q->mq_ops->queue_rq(hctx, &bd);
>>>>>>>>  		if (ret == BLK_STS_RESOURCE) {
>>>>>>>> +			/*
>>>>>>>> +			 * If an I/O scheduler has been configured and we got a
>>>>>>>> +			 * driver tag for the next request already, free it again.
>>>>>>>> +			 */
>>>>>>>> +			if (!list_empty(list)) {
>>>>>>>> +				nxt = list_first_entry(list, struct request, queuelist);
>>>>>>>> +				blk_mq_put_driver_tag(nxt);
>>>>>>>> +			}
>>>>>>> The following way might be more simple and clean:
>>>>>>>
>>>>>>> 			if (nxt)
>>>>>>> 				blk_mq_put_driver_tag(nxt);
>>>>>>>
>>>>>>> meantime 'nxt' need to be cleared inside the 'if (list_empty(list))'
>>>>>>> before .queue_rq().
>>>>>> I had ever thought about that, but to avoid add extra command in the 
>>>>>> fast path, I made the patch above.
>>>>> Got it, so how about changing to the following way simply:
>>>>>
>>>>>  			if (nxt && !list_empty(list))
>>>>>  				blk_mq_put_driver_tag(nxt);
>>>>>
>>>> It seems that we even could change it as following:
>>>>                         if (!list_empty(list))
>>>>   				blk_mq_put_driver_tag(nxt);
>>> This is starting to get too clever for its own good, I generally don't
>>> like to sacrifice readability for performance. In reality, the compiler
>>> probably figures it out anyway...
>>>
>>> So either make it explicit, or add a nice comment as to why it is the
>>> way that it is.
>>>
>> yes, it indeed leads to compiler warning of "may be used uninitialized"
>> maybe the original one could be taken back.
>> 			if (!list_empty(list)) {
>> 				nxt = list_first_entry(list, struct request, queuelist);
>> 				blk_mq_put_driver_tag(nxt);
>> 			}
>> It is more readable and could avoid the warning.
> Exactly, and especially the readability is the key element here. It's
> just not worth it to try and be too clever, especially not for something
> like this. When you read the above, you immediately know what the code
> does without needing a comment. That's not true for the other construct.
> You both have to read other parts of the function to figure out what it
> does, AND read the entire function to ensure it always does the right
> thing. Fragile.

Thanks for your comments , jens and ming. I'm really appreciative of that.
About the fragility, do you mean the possibility that may release the tag of the next rq
which has a driver tag itself (maybe a flush) ?

Thanks
jianchao

  reply	other threads:[~2017-09-13  3:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-12 17:14 [PATCH] blk-mq: put the driver tag of nxt rq before first one is requeued Jianchao Wang
2017-09-12 10:23 ` Ming Lei
2017-09-13  1:01   ` jianchao.wang
2017-09-13  1:24     ` Ming Lei
2017-09-13  1:39       ` jianchao.wang
2017-09-13  1:52         ` Ming Lei
2017-09-13  2:23         ` Jens Axboe
2017-09-13  2:42           ` jianchao.wang
2017-09-13  2:45             ` Jens Axboe
2017-09-13  3:39               ` jianchao.wang [this message]
2017-09-13  3:54                 ` Jens Axboe
2017-09-13  3:59                   ` jianchao.wang
2017-09-13  3:50               ` Ming Lei

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=aebfc622-6d7d-0d07-5a13-8dae06a49bb7@oracle.com \
    --to=jianchao.w.wang@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox