Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp2097556rwo; Thu, 3 Aug 2023 04:49:29 -0700 (PDT) X-Google-Smtp-Source: APBJJlHYxzChivtPc/PLVkuhu82xL95ABdb6MmPK9JGjsZpwFZgEwusb2olxY5/2pBm8ArHz/K2u X-Received: by 2002:a17:902:cecb:b0:1bb:a922:4a1a with SMTP id d11-20020a170902cecb00b001bba9224a1amr19488916plg.6.1691063369435; Thu, 03 Aug 2023 04:49:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691063369; cv=none; d=google.com; s=arc-20160816; b=zpsvbvW32xQ3jCdkT8ZLi3QXNLRx4NZvLSosON1ukuvxUy3ozqYeyVI0HiOofbji4p QmK1h3kT8VqwgBry6PgJDUwBs6an1u8SuHYeT3T67tOxwSRKj1ICfbyEEAdhVGJ8X3vx iG+UNbluausIo2qO9KYd42C1aKXhrsp22MtQyqHXHD8+FNUATxh2HJVcuhG1LtX1uxRg G9GL31yS10NvM7eV5rkzE09sRByhB83DO08TauOLOp6hseVeeIaRUmZILkSom/PTYDJz ikURx3WFResfS959szidIPMu69LBdr8qjyOwkwDLvhvCZjSks4dbqXO8Wt+u+YRZjNF+ nB/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=loIvy8EpCOBbBGmIcDS0k528os20mA0dhwl2k20P7DM=; fh=fGEMoNtnaaYcAgsyua0vIZs3HXPcmOz40+icvjXoRGY=; b=U1zfraplAcywGQlamlPRs3wrFokla2HiqnTl1kC3bws3cgSfwidKjczHk6wd/SV/2B RfiE3jR1fdkOaOdBLJ+QNSzOL7oluC88u6EXnQoJEZo7gy77o1lILbAnknWD8C29vhjb mNOAcrToH5jSK0uNaXd08h3Lt7q1aXVW+/uPrnSOKQCGvobRLgLEfKxfUIFL0PtUijVe eJRRZOadaw9HnyEtJtbkjRzu8ghhw3F2VqH3KTqQXYLb2FZo25YzTNxMhfkx5um7kteh G8E9N4+/0vzdLmWHdQ3/OVWFlJmULK7U9Z2w8gADw9w+4qF6Xxe6ASN80X0RMkShy6kO 688w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j8-20020a170903024800b001bb377f8c8bsi13065976plh.2.2023.08.03.04.49.16; Thu, 03 Aug 2023 04:49:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234004AbjHCLOr (ORCPT + 99 others); Thu, 3 Aug 2023 07:14:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233764AbjHCLOq (ORCPT ); Thu, 3 Aug 2023 07:14:46 -0400 Received: from SHSQR01.spreadtrum.com (mx1.unisoc.com [222.66.158.135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E77E9B; Thu, 3 Aug 2023 04:14:43 -0700 (PDT) Received: from dlp.unisoc.com ([10.29.3.86]) by SHSQR01.spreadtrum.com with ESMTP id 373BEBdF048295; Thu, 3 Aug 2023 19:14:11 +0800 (+08) (envelope-from Zhiguo.Niu@unisoc.com) Received: from SHDLP.spreadtrum.com (bjmbx02.spreadtrum.com [10.0.64.8]) by dlp.unisoc.com (SkyGuard) with ESMTPS id 4RGmQf3WpJz2Nwpsg; Thu, 3 Aug 2023 19:12:26 +0800 (CST) Received: from bj08434pcu.spreadtrum.com (10.0.73.87) by BJMBX02.spreadtrum.com (10.0.64.8) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 3 Aug 2023 19:14:09 +0800 From: Zhiguo Niu To: , CC: , , , , , Subject: [PATCH] block/mq-deadline: use correct way to throttling write requests Date: Thu, 3 Aug 2023 19:12:42 +0800 Message-ID: <1691061162-22898-1-git-send-email-zhiguo.niu@unisoc.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.0.73.87] X-ClientProxiedBy: SHCAS01.spreadtrum.com (10.0.1.201) To BJMBX02.spreadtrum.com (10.0.64.8) X-MAIL: SHSQR01.spreadtrum.com 373BEBdF048295 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The original formula was inaccurate: dd->async_depth = max(1UL, 3 * q->nr_requests / 4); For write requests, when we assign a tags from sched_tags, data->shallow_depth will be passed to sbitmap_find_bit, see the following code: nr = sbitmap_find_bit_in_word(&sb->map[index], min_t (unsigned int, __map_depth(sb, index), depth), alloc_hint, wrap); The smaller of data->shallow_depth and __map_depth(sb, index) will be used as the maximum range when allocating bits. For a mmc device (one hw queue, deadline I/O scheduler): q->nr_requests = sched_tags = 128, so according to the previous calculation method, dd->async_depth = data->shallow_depth = 96, and the platform is 64bits with 8 cpus, sched_tags.bitmap_tags.sb.shift=5, sb.maps[]=32/32/32/32, 32 is smaller than 96, whether it is a read or a write I/O, tags can be allocated to the maximum range each time, which has not throttling effect. In addition, refer to the methods of bfg/kyber I/O scheduler, limit ratiois are calculated base on sched_tags.bitmap_tags.sb.shift. This patch can throttle write requests really. Fixes: 07757588e507 ("block/mq-deadline: Reserve 25% of scheduler tags for synchronous requests") Signed-off-by: Zhiguo Niu --- block/mq-deadline.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/block/mq-deadline.c b/block/mq-deadline.c index 5839a027e0f0..7e043d4a78f8 100644 --- a/block/mq-deadline.c +++ b/block/mq-deadline.c @@ -620,8 +620,9 @@ static void dd_depth_updated(struct blk_mq_hw_ctx *hctx) struct request_queue *q = hctx->queue; struct deadline_data *dd = q->elevator->elevator_data; struct blk_mq_tags *tags = hctx->sched_tags; + unsigned int shift = tags->bitmap_tags.sb.shift; - dd->async_depth = max(1UL, 3 * q->nr_requests / 4); + dd->async_depth = max(1U, 3 * (1U << shift) / 4); sbitmap_queue_min_shallow_depth(&tags->bitmap_tags, dd->async_depth); } -- 2.37.3