Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp467177pxb; Tue, 14 Sep 2021 01:25:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwSJL6SUQ/9oRRHHJdMvD6SJRNKo5kD8T7vJQcVlbJKfGDJCeG9v8DlOfyjgS5s8wOip1uO X-Received: by 2002:a17:906:63ca:: with SMTP id u10mr17481833ejk.411.1631607956412; Tue, 14 Sep 2021 01:25:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631607956; cv=none; d=google.com; s=arc-20160816; b=wGHdU1hTIZHY/IYACBji87+rCs0oYpygRgphofCfjWfO6G7qL98iDJRMtxSrLaQ8JJ eVBU6geruQqk3quVCs2WLP9C8LjmyvtvyrSIohXnOV/8kW502KWDTeYez8YNqz9DrRb6 nrIBMTu1kPxgnDQK6Bqbsud2gcichWz3ej5tfLCftu39+KlYYiKnEHD60bgEx/rMScih yaVb89eo/U8wMtMVLf0tqgKQMpDPOJCIVgkTH7IC2xGDLS2308PtsJm97tNw76F4FsbA wcRbW1bfGSvPmwayEASugMiCLWPS5LJzLiQE4lBwFiVs+8jQhHJebylDCMeBS1JnkN34 rAOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=fLjNYe1cKQFUld4xPZUfdMvifhB/cqDkEu5qg5wJQGA=; b=BDALxkeOISLAW7EZYFuzUOOOiEI68/b4ksAFe5WeYuJCfL4We0qlNeeZoFt+Pu3Bbw qsrmoCBkOgasI1RgQIngJr5kHW6l5HN61Z7lGpjYu1sRC05pUEt8jsMOC4JkEeZ4De+6 7W3ETnkL4KSEsRYAMFayFnGunyXLt1Ee3XtyJvQJuV3Ce4YKZqKyiEE0iJwCcnKyuha4 Y9z7RWLsQfpGKpCitRINmAnZW9cQXWlOi2bmsGB+Z0vg5602hgXjB+rhUP5V6aWBL0uq 8m5UfTK2lAQS2EAhavRBN2xK/ErGkBLvCCqDgEbSty3rln6QlAxmql6QCVgdgek9EtCi Ucsg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q17si11322987edd.616.2021.09.14.01.25.31; Tue, 14 Sep 2021 01:25:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229829AbhINIYq (ORCPT + 99 others); Tue, 14 Sep 2021 04:24:46 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]:3787 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229458AbhINIYq (ORCPT ); Tue, 14 Sep 2021 04:24:46 -0400 Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4H7xBk0RTxz67Xb5; Tue, 14 Sep 2021 16:21:18 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 14 Sep 2021 10:23:25 +0200 Received: from [10.47.80.114] (10.47.80.114) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 14 Sep 2021 09:23:25 +0100 Subject: Re: [PATCH RESEND v3 12/13] blk-mq: Use shared tags for shared sbitmap support To: Hannes Reinecke , "axboe@kernel.dk" CC: "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "ming.lei@redhat.com" , "linux-scsi@vger.kernel.org" References: <1631545950-56586-1-git-send-email-john.garry@huawei.com> <1631545950-56586-13-git-send-email-john.garry@huawei.com> <05804d91-4392-260d-34f2-618b0d3b3f7f@suse.de> From: John Garry Message-ID: <664ba62f-ccbf-ac0c-548e-e15561b82224@huawei.com> Date: Tue, 14 Sep 2021 09:27:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <05804d91-4392-260d-34f2-618b0d3b3f7f@suse.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.47.80.114] X-ClientProxiedBy: lhreml754-chm.china.huawei.com (10.201.108.204) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ... >> static int blk_mq_init_sched_shared_sbitmap(struct request_queue *queue) >> { >> struct blk_mq_tag_set *set = queue->tag_set; >> - int alloc_policy = BLK_MQ_FLAG_TO_ALLOC_POLICY(set->flags); >> - struct blk_mq_hw_ctx *hctx; >> - int ret, i; >> >> /* >> * Set initial depth at max so that we don't need to reallocate for >> * updating nr_requests. >> */ >> - ret = blk_mq_init_bitmaps(&queue->sched_bitmap_tags, >> - &queue->sched_breserved_tags, >> - MAX_SCHED_RQ, set->reserved_tags, >> - set->numa_node, alloc_policy); >> - if (ret) >> - return ret; >> - >> - queue_for_each_hw_ctx(queue, hctx, i) { >> - hctx->sched_tags->bitmap_tags = >> - &queue->sched_bitmap_tags; >> - hctx->sched_tags->breserved_tags = >> - &queue->sched_breserved_tags; >> - } >> + queue->shared_sbitmap_tags = blk_mq_alloc_map_and_rqs(set, >> + BLK_MQ_NO_HCTX_IDX, >> + MAX_SCHED_RQ); >> + if (!queue->shared_sbitmap_tags) >> + return -ENOMEM; >> > > Any particular reason why the 'shared_sbitmap_tags' pointer is added to > the request queue and not the tagset? > Everything else is located there, so I would have found it more logical > to add the 'shared_sbitmap_tags' pointer to the tagset, not the queue ... > We already have it for both. Since commit d97e594c5166 ("blk-mq: Use request queue-wide tags for tagset-wide sbitmap"), we have a "shared sbitmap" per tagset and per request queue. If you check d97e594c5166 then it should explain the reason. >> blk_mq_tag_update_sched_shared_sbitmap(queue); >> >> return 0; >> } >> >> -static void blk_mq_exit_sched_shared_sbitmap(struct request_queue *queue) >> -{ >> - sbitmap_queue_free(&queue->sched_bitmap_tags); >> - sbitmap_queue_free(&queue->sched_breserved_tags); >> -} >> - >> int blk_mq_init_sched(struct request_queue *q, struct elevator_type *e) >> { >> + unsigned int i, flags = q->tag_set->flags; >> struct blk_mq_hw_ctx *hctx; >> struct elevator_queue *eq; >> - unsigned int i; >> int ret; >> >> if (!e) { >> @@ -598,21 +596,21 @@ int blk_mq_init_sched(struct request_queue *q, struct elevator_type *e) >> q->nr_requests = 2 * min_t(unsigned int, q->tag_set->queue_depth, >> BLKDEV_DEFAULT_RQ); >> >> - queue_for_each_hw_ctx(q, hctx, i) { >> - ret = blk_mq_sched_alloc_map_and_rqs(q, hctx, i); >> + if (blk_mq_is_sbitmap_shared(flags)) { >> + ret = blk_mq_init_sched_shared_sbitmap(q); > if (ret) >> - goto err_free_map_and_rqs; >> + return ret; >> } >> >> - if (blk_mq_is_sbitmap_shared(q->tag_set->flags)) { >> - ret = blk_mq_init_sched_shared_sbitmap(q); >> + queue_for_each_hw_ctx(q, hctx, i) { >> + ret = blk_mq_sched_alloc_map_and_rqs(q, hctx, i); >> if (ret) >> goto err_free_map_and_rqs; >> } >> >> ret = e->ops.init_sched(q, e); >> if (ret) >> - goto err_free_sbitmap; >> + goto err_free_map_and_rqs; >> >> blk_mq_debugfs_register_sched(q); >> >> @@ -632,12 +630,10 @@ int blk_mq_init_sched(struct request_queue *q, struct elevator_type *e) >> >> return 0; >> >> -err_free_sbitmap: >> - if (blk_mq_is_sbitmap_shared(q->tag_set->flags)) >> - blk_mq_exit_sched_shared_sbitmap(q); >> - blk_mq_sched_free_rqs(q); >> err_free_map_and_rqs: >> - blk_mq_sched_tags_teardown(q); >> + blk_mq_sched_free_rqs(q); >> + blk_mq_sched_tags_teardown(q, flags); >> + >> q->elevator = NULL; >> return ret; >> } >> @@ -651,9 +647,15 @@ void blk_mq_sched_free_rqs(struct request_queue *q) >> struct blk_mq_hw_ctx *hctx; >> int i; >> >> - queue_for_each_hw_ctx(q, hctx, i) { >> - if (hctx->sched_tags) >> - blk_mq_free_rqs(q->tag_set, hctx->sched_tags, i); >> + if (blk_mq_is_sbitmap_shared(q->tag_set->flags)) { >> + blk_mq_free_rqs(q->tag_set, q->shared_sbitmap_tags, >> + BLK_MQ_NO_HCTX_IDX); > > 'if (q->shared_sbitmap_tags)' > > would be more obvious here ... I suppose so. I am just doing it this way for consistency. > >> + } else { >> + queue_for_each_hw_ctx(q, hctx, i) { >> + if (hctx->sched_tags) >> + blk_mq_free_rqs(q->tag_set, >> + hctx->sched_tags, i); >> + } >> } >> } >> ... >> }; >> @@ -432,6 +429,8 @@ enum { >> ((policy & ((1 << BLK_MQ_F_ALLOC_POLICY_BITS) - 1)) \ >> << BLK_MQ_F_ALLOC_POLICY_START_BIT) >> >> +#define BLK_MQ_NO_HCTX_IDX (-1U) >> + >> struct gendisk *__blk_mq_alloc_disk(struct blk_mq_tag_set *set, void *queuedata, >> struct lock_class_key *lkclass); >> #define blk_mq_alloc_disk(set, queuedata) \ >> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h >> index 4baf9435232d..17e50e5ef47b 100644 >> --- a/include/linux/blkdev.h >> +++ b/include/linux/blkdev.h >> @@ -459,8 +459,7 @@ struct request_queue { >> >> atomic_t nr_active_requests_shared_sbitmap; >> >> - struct sbitmap_queue sched_bitmap_tags; >> - struct sbitmap_queue sched_breserved_tags; >> + struct blk_mq_tags *shared_sbitmap_tags; >> >> struct list_head icq_list; >> #ifdef CONFIG_BLK_CGROUP >> > Why the double shared_sbitmap_tags pointer in struct request_queue and > struct tag_set? To my knowledge there's a 1:1 relationship between > request_queue and tag_set, so where's the point? > As above, we also added a shared sbitmap per request queue. The reason being that for "shared sbitmap" support, the request queue total depth should not grow for an increase in the number of HW queues. Thanks, John