From patchwork Thu Mar 14 01:03:17 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Zhiguo Niu X-Patchwork-Id: 13592020 Received: from SHSQR01.spreadtrum.com (unknown [222.66.158.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05BA6EDE; Thu, 14 Mar 2024 01:03:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=222.66.158.135 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710378237; cv=none; b=n0PFK35JkxltLwSmHS8nsNpo/ruziSVvVAhfg/2Kg3o10Kf5E2/svOIALd0DyT+nbAnGWlA+Q01Er8jHzO4isr5MGDzSWeAZZQEtm2q5EyGaWaDH1UQ7TaEn+SEAqKFVQgx0IQZB3uVKqYbJFNAJNPpUwfPqf9P1zzysA/kKE+0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710378237; c=relaxed/simple; bh=bf/vjg/qaqi/ER/iveqlpt38o7vUIGhHSU47DZ/UJaE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=HiD1ulcOiHovi9JhBcy1yy1w+AQdW2os1BfNEzpczAaEcAHn1oNvkU3gpDFx72KBNrUGhpo6nbmljprnu6Fsf8BwQ8lBQIXEVsq88mKyY3MUBJhuORmpXy0UxmgQe4uDID2OQN3Bxd2vgR8S7g88cHdp8wDKJT9E/c+pHZRzc4c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=unisoc.com; spf=pass smtp.mailfrom=unisoc.com; arc=none smtp.client-ip=222.66.158.135 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=unisoc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=unisoc.com Received: from dlp.unisoc.com ([10.29.3.86]) by SHSQR01.spreadtrum.com with ESMTP id 42E13LGj084497; Thu, 14 Mar 2024 09:03:21 +0800 (+08) (envelope-from Zhiguo.Niu@unisoc.com) Received: from SHDLP.spreadtrum.com (bjmbx01.spreadtrum.com [10.0.64.7]) by dlp.unisoc.com (SkyGuard) with ESMTPS id 4Tw8Gz2zcXz2L1Lpm; Thu, 14 Mar 2024 09:02:03 +0800 (CST) Received: from BJMBX02.spreadtrum.com (10.0.64.8) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 14 Mar 2024 09:03:18 +0800 Received: from BJMBX02.spreadtrum.com ([fe80::c8c3:f3a0:9c9f:b0fb]) by BJMBX02.spreadtrum.com ([fe80::c8c3:f3a0:9c9f:b0fb%19]) with mapi id 15.00.1497.023; Thu, 14 Mar 2024 09:03:18 +0800 From: =?utf-8?b?54mb5b+X5Zu9IChaaGlndW8gTml1KQ==?= To: Bart Van Assche , Jens Axboe CC: "linux-block@vger.kernel.org" , "Christoph Hellwig" , "stable@vger.kernel.org" , Damien Le Moal , Harshit Mogalapalli , =?utf-8?b?6YeR57qi?= =?utf-8?b?5a6HIChIb25neXUgSmluKQ==?= Subject: =?utf-8?q?=E7=AD=94=E5=A4=8D=3A_=5BPATCH=5D_Revert_=22block/mq-dead?= =?utf-8?q?line=3A_use_correct_way_to_throttling_write_requests=22?= Thread-Topic: [PATCH] Revert "block/mq-deadline: use correct way to throttling write requests" Thread-Index: AQHadY9udLecnqbSDUSAXigHuLhvL7E2aiUA Date: Thu, 14 Mar 2024 01:03:17 +0000 Message-ID: References: <20240313214218.1736147-1-bvanassche@acm.org> In-Reply-To: <20240313214218.1736147-1-bvanassche@acm.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MAIL: SHSQR01.spreadtrum.com 42E13LGj084497 Hi Bart, Just as mentioned in original patch, "dd->async_depth = max(1UL, 3 * q->nr_requests / 4);", this limitation methods look likes won't have a limit effect, because tag allocated is based on sbitmap, not based the whole nr_requests. Right? Thanks! 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. -----邮件原件----- 发件人: Bart Van Assche 发送时间: 2024年3月14日 5:42 收件人: Jens Axboe 抄送: linux-block@vger.kernel.org; Christoph Hellwig ; Bart Van Assche ; stable@vger.kernel.org; Damien Le Moal ; Harshit Mogalapalli ; 牛志国 (Zhiguo Niu) 主题: [PATCH] Revert "block/mq-deadline: use correct way to throttling write requests" 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. The code "max(1U, 3 * (1U << shift) / 4)" comes from the Kyber I/O scheduler. The Kyber I/O scheduler maintains one internal queue per hwq and hence derives its async_depth from the number of hwq tags. Using this approach for the mq-deadline scheduler is wrong since the mq-deadline scheduler maintains one internal queue for all hwqs combined. Hence this revert. Cc: stable@vger.kernel.org Cc: Damien Le Moal Cc: Harshit Mogalapalli Cc: Zhiguo Niu Fixes: d47f9717e5cf ("block/mq-deadline: use correct way to throttling write requests") Signed-off-by: Bart Van Assche --- block/mq-deadline.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/block/mq-deadline.c b/block/mq-deadline.c index f958e79277b8..02a916ba62ee 100644 --- a/block/mq-deadline.c +++ b/block/mq-deadline.c @@ -646,9 +646,8 @@ 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(1U, 3 * (1U << shift) / 4); + dd->async_depth = max(1UL, 3 * q->nr_requests / 4); sbitmap_queue_min_shallow_depth(&tags->bitmap_tags, dd->async_depth); }