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
