| Message ID | 1655463320-241202-1-git-send-email-john.garry@huawei.com |
|---|---|
| Headers | show |
| Series | blk-mq: Add a flag for reserved requests series | expand |
On 6/17/22 03:55, John Garry wrote: > With new API blk_mq_is_reserved_rq() we can tell if a request is from > the reserved pool, so stop passing 'reserved' arg. There is actually > only a single user of that arg for all the callback implementations, which > can use blk_mq_is_reserved_rq() instead. > > This will also allow us to stop passing the same 'reserved' around the > blk-mq iter functions next. Reviewed-by: Bart Van Assche <bvanassche@acm.org>
On 6/17/22 03:55, John Garry wrote: > We no longer use the 'reserved' member in for any iter function so it ^^^^^^ One of these two words probably should be removed. > diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c > index 2dcd738c6952..b8cc8b41553f 100644 > --- a/block/blk-mq-tag.c > +++ b/block/blk-mq-tag.c > @@ -266,7 +266,6 @@ static bool bt_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data) > struct blk_mq_hw_ctx *hctx = iter_data->hctx; > struct request_queue *q = iter_data->q; > struct blk_mq_tag_set *set = q->tag_set; > - bool reserved = iter_data->reserved; > struct blk_mq_tags *tags; > struct request *rq; > bool ret = true; > @@ -276,7 +275,7 @@ static bool bt_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data) > else > tags = hctx->tags; > > - if (!reserved) > + if (!iter_data->reserved) > bitnr += tags->nr_reserved_tags; > /* > * We can hit rq == NULL here, because the tagging functions Is the above change really necessary? > @@ -337,12 +336,11 @@ static bool bt_tags_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data) > { > struct bt_tags_iter_data *iter_data = data; > struct blk_mq_tags *tags = iter_data->tags; > - bool reserved = iter_data->flags & BT_TAG_ITER_RESERVED; > struct request *rq; > bool ret = true; > bool iter_static_rqs = !!(iter_data->flags & BT_TAG_ITER_STATIC_RQS); > > - if (!reserved) > + if (!(iter_data->flags & BT_TAG_ITER_RESERVED)) > bitnr += tags->nr_reserved_tags; > > /* Same question here: is the above change really necessary? Thanks, Bart.
On 6/17/22 09:42, John Garry wrote: > On 17/06/2022 17:33, Bart Van Assche wrote: >> On 6/17/22 03:55, John Garry wrote: >>> @@ -276,7 +275,7 @@ static bool bt_iter(struct sbitmap *bitmap, >>> unsigned int bitnr, void *data) >>> else >>> tags = hctx->tags; >>> - if (!reserved) >>> + if (!iter_data->reserved) >>> bitnr += tags->nr_reserved_tags; >>> /* >>> * We can hit rq == NULL here, because the tagging functions >> >> Is the above change really necessary? > > It's not totally necessary. Since local variable 'reserved' would now > only be used once I thought it was better to get rid of it. > > I can keep it if you really think that is better. I'd prefer that these changes are either left out or that these are moved into a separate patch. I think that will make this patch series easier to review. Thanks, Bart.
On 17/06/2022 17:55, Bart Van Assche wrote: >> >> It's not totally necessary. Since local variable 'reserved' would now >> only be used once I thought it was better to get rid of it. >> >> I can keep it if you really think that is better. > > I'd prefer that these changes are either left out or that these are > moved into a separate patch. I think that will make this patch series > easier to review. Personally I think that this is a trivial change and does not merit a separate patch. Other reviewers seem to agree. Anyway, if you feel strongly about this then I can put in another patch. Thanks, John
John, > In [0] I included "blk-mq: Add a flag for reserved requests" to > identify if a request is 'reserved' for special handling. Doing this > is easier than passing a 'reserved' arg to the blk_mq_ops > callbacks. Indeed, only 1x timeout implementation or blk-mq iter > function actually uses the 'reserved' arg (or 3x if you count SCSI > core and FNIC SCSI driver). So this series drops the 'reserved' arg > for these timeout and iter functions. Christoph suggested that I try > to upstream now. Looks OK to me. I agree with the scsi_timeout() suggestion. Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>