From nobody Thu Sep 24 20:30:51 2026 Received: from mta0.migadu.com (out-81.mta0.migadu.com [91.218.175.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12DBB1A6815 for ; Mon, 21 Sep 2026 03:35:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.81 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789961742; cv=none; b=ZyL9XY+KtlZHOQiD5daoBkuHZzPxWQpyAAEZ7jocyjj3YveHlp9cyw+i6LCD5SVcCs+zGaI3R9lRngeSGpeQtELEN1cVM5m0QMLj/k3P4yrSyajiUWSdeXybZlJHS4ZIHeJGEa7ZhmZdhoDv0AmdDGpGlT/U4TdJdd5q6kt4a6s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789961742; c=relaxed/simple; bh=UPxjJaMy+kywgd+ZqUtAsBcW7lmrQMuEb3whwTHYe3U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IlFfqwIhewlkyNoT+jqkfJ5n6k9pGlyOWiDdROE2XDtCSf+J5dQtd4w21/WhhINfSskY0bFdmd0UQilYyY5aXrcvQYgOfHXXBoL2kdzRr/Iacj8rtcSX89fHx78lVF530fHKOw2iT4q4+gk8H44lGpOFpcByPaO12NAU7TlKifM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Ob+6SPyJ; arc=none smtp.client-ip=91.218.175.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Ob+6SPyJ" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=UPxjJaMy+kywgd+ZqUtAsBcW7lmrQMuEb3whwTHYe3U=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789961737; v=1; x=1790566537; b=Ob+6SPyJVwgWCssumHPTRPuGqtHd4k0cd/yd40g18SOUaPBdNKkYSGkJ+BsjcYiBYWWOOPse G6AfyV56YNNMh2h/ckRCLvAwsVfpKsx+Mv2tq7oQgKcOMVsH1Nd6kyWK869Pos58U2HEFDtMVoN Lget8I750eKQ7U9ivziNC4p0= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id dff60e5ed33885bc; Mon, 21 Sep 2026 03:35:11 +0000 X-Mizu-Trace-ID: dff60e5ed33885bc X-Migadu-Flow: FLOW_OUT From: Tao Cui To: tj@kernel.org, josef@toxicpanda.com, axboe@kernel.dk, hch@infradead.org Cc: cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, cui.tao@linux.dev, cuitao@kylinos.cn Subject: [PATCH v3 1/4] blk-iocost: add flush cost support with the flushiops model parameter Date: Mon, 21 Sep 2026 11:34:50 +0800 Message-ID: <20260921033453.1912971-2-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260921033453.1912971-1-cui.tao@linux.dev> References: <20260921033453.1912971-1-cui.tao@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tao Cui The builtin linear cost model defines coefficients only for READ and WRITE, so the flush component of IOs is priced at zero: standalone flushes (the dataless REQ_OP_WRITE | REQ_PREFLUSH bios from blkdev_issue_flush()) and the pre-flush the block layer issues ahead of data-bearing REQ_PREFLUSH bios are both free. A cgroup limited to 1% weight could issue an unbounded number of flushes without being throttled: an fsync loop produced ~510k flushes in 12s with cost.usage staying at zero, monopolizing the device while iocost reported no activity. On ext4, a write+fsync workload showed the same gap: the write component was charged but the flush component was not. A flush is not like a write and the write coefficients say nothing about what it costs, so instead of pricing it off them, add a flushiops entry to io.cost.model, following the existing iops parameters: it sets the rate at which flushes are charged, translated like the other iops coefficients to LCOEF_FLUSH =3D VTIME_PER_SEC / flushiops. The linear model cannot express how the cost of a flush depends on the preceding writes, so this is a user-tunable policy knob rather than a hardware property. A bio with REQ_PREFLUSH is charged one flush on top of its data cost, and a bio with REQ_FUA one more flush on devices without native FUA support, mirroring the pre-flush and post-flush the block layer issues for them. Zero (the default and the builtin profiles) means no charge, so nothing changes until the parameter is configured. Also skip the iocg->cursor update for dataless bios: they only reach it once priced, and their bi_sector is not a data position, so setting the cursor from it would misclassify the following IOs. Signed-off-by: Tao Cui Acked-by: Tejun Heo --- Documentation/admin-guide/cgroup-v2.rst | 8 ++++++ block/blk-iocost.c | 37 +++++++++++++++++++++---- 2 files changed, 40 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-= guide/cgroup-v2.rst index 8d2603751c51..5a6ba29b7789 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -2131,6 +2131,7 @@ IO Interface Files [r|w]bps The maximum sequential IO throughput [r|w]seqiops The maximum 4k sequential IOs per second [r|w]randiops The maximum 4k random IOs per second + flushiops The rate at which flushes are charged =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =20 From the above, the builtin linear model determines the base @@ -2138,6 +2139,13 @@ IO Interface Files for the IO size. While simple, this model can cover most common device classes acceptably. =20 + "flushiops" determines the cost of a cache flush: a bio with + REQ_PREFLUSH is charged one flush on top of its data cost, and + a bio with REQ_FUA is charged one more flush on devices without + native FUA support, mirroring the pre-flush and post-flush the + block layer issues for them. It is zero in the builtin + profiles, so flushes stay free until it is configured. + The IO cost model isn't expected to be accurate in absolute sense and is scaled to the device behavior dynamically. =20 diff --git a/block/blk-iocost.c b/block/blk-iocost.c index 2745bffcd5ee..0a0352554dde 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -353,6 +353,7 @@ enum { I_LCOEF_WBPS, I_LCOEF_WSEQIOPS, I_LCOEF_WRANDIOPS, + I_LCOEF_FLUSHIOPS, NR_I_LCOEFS, }; =20 @@ -363,6 +364,7 @@ enum { LCOEF_WPAGE, LCOEF_WSEQIO, LCOEF_WRANDIO, + LCOEF_FLUSH, NR_LCOEFS, }; =20 @@ -883,6 +885,9 @@ static void ioc_refresh_lcoefs(struct ioc *ioc) &c[LCOEF_RPAGE], &c[LCOEF_RSEQIO], &c[LCOEF_RRANDIO]); calc_lcoefs(u[I_LCOEF_WBPS], u[I_LCOEF_WSEQIOPS], u[I_LCOEF_WRANDIOPS], &c[LCOEF_WPAGE], &c[LCOEF_WSEQIO], &c[LCOEF_WRANDIO]); + + c[LCOEF_FLUSH] =3D u[I_LCOEF_FLUSHIOPS] ? + DIV64_U64_ROUND_UP(VTIME_PER_SEC, u[I_LCOEF_FLUSHIOPS]) : 0; } =20 /* @@ -2532,8 +2537,25 @@ static void calc_vtime_cost_builtin(struct bio *bio,= struct ioc_gq *iocg, u64 pages =3D max_t(u64, bio_sectors(bio) >> IOC_SECT_TO_PAGE_SHIFT, 1); u64 seek_pages =3D 0; u64 cost =3D 0; + u64 flush_cost =3D 0; + + /* + * The flush machine runs a cache flush for REQ_PREFLUSH, either + * standalone (dataless) or ahead of the data, and a post-flush for + * REQ_FUA on devices without native FUA support. Charge each + * component on top of the data cost using the flush coefficient + * (VTIME_PER_SEC / flushiops; zero when flushiops is unset). Flush + * bios are never merged. + */ + if (!is_merge) { + if (bio->bi_opf & REQ_PREFLUSH) + flush_cost +=3D ioc->params.lcoefs[LCOEF_FLUSH]; + if ((bio->bi_opf & REQ_FUA) && + !bdev_fua(bio->bi_bdev)) + flush_cost +=3D ioc->params.lcoefs[LCOEF_FLUSH]; + } =20 - /* Can't calculate cost for empty bio */ + /* Can't calculate data cost for empty bio */ if (!bio->bi_iter.bi_size) goto out; =20 @@ -2566,7 +2588,7 @@ static void calc_vtime_cost_builtin(struct bio *bio, = struct ioc_gq *iocg, } cost +=3D pages * coef_page; out: - *costp =3D cost; + *costp =3D cost + flush_cost; } =20 static u64 calc_vtime_cost(struct bio *bio, struct ioc_gq *iocg, bool is_m= erge) @@ -2708,7 +2730,9 @@ static void ioc_rqos_throttle(struct rq_qos *rqos, st= ruct bio *bio) if (!iocg_activate(iocg, &now)) return; =20 - iocg->cursor =3D bio_end_sector(bio); + /* dataless bios have no meaningful position for seq/rand detection */ + if (bio->bi_iter.bi_size) + iocg->cursor =3D bio_end_sector(bio); vtime =3D atomic64_read(&iocg->vtime); cost =3D adjust_inuse_and_calc_cost(iocg, vtime, abs_cost, &now); =20 @@ -3440,10 +3464,12 @@ static u64 ioc_cost_model_prfill(struct seq_file *s= f, spin_lock_irq(&ioc->lock); seq_printf(sf, "%s ctrl=3D%s model=3Dlinear " "rbps=3D%llu rseqiops=3D%llu rrandiops=3D%llu " - "wbps=3D%llu wseqiops=3D%llu wrandiops=3D%llu\n", + "wbps=3D%llu wseqiops=3D%llu wrandiops=3D%llu " + "flushiops=3D%llu\n", dname, ioc->user_cost_model ? "user" : "auto", u[I_LCOEF_RBPS], u[I_LCOEF_RSEQIOPS], u[I_LCOEF_RRANDIOPS], - u[I_LCOEF_WBPS], u[I_LCOEF_WSEQIOPS], u[I_LCOEF_WRANDIOPS]); + u[I_LCOEF_WBPS], u[I_LCOEF_WSEQIOPS], u[I_LCOEF_WRANDIOPS], + u[I_LCOEF_FLUSHIOPS]); spin_unlock_irq(&ioc->lock); return 0; } @@ -3470,6 +3496,7 @@ static const match_table_t i_lcoef_tokens =3D { { I_LCOEF_WBPS, "wbps=3D%u" }, { I_LCOEF_WSEQIOPS, "wseqiops=3D%u" }, { I_LCOEF_WRANDIOPS, "wrandiops=3D%u" }, + { I_LCOEF_FLUSHIOPS, "flushiops=3D%u" }, { NR_I_LCOEFS, NULL }, }; =20 --=20 2.43.0 From nobody Thu Sep 24 20:30:51 2026 Received: from mta0.migadu.com (out-83.mta0.migadu.com [91.218.175.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4B3A337699 for ; Mon, 21 Sep 2026 03:35:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.83 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789961745; cv=none; b=ICsis0L7ObxkVvs3BAGL6AKE5ihKqFgU7/wD+QpOxoKpxSS6QxRnRYkIUplQSz8Wxo+KAF59q4umd6qyO0ZqBdIkQOs0ro734p73W4SqnbLZIKsCfFnq1WlSB2wTY5sN1fvuPwKX3ZFIVJi7gqUhbw8h0OaEDHaCxO/RiqD5PPI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789961745; c=relaxed/simple; bh=jw+HNZ/h0ecwFOQQg0GRnVDRu6AYuC2p1m3XOQpGwWI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gBzcLZdjrqGZvznnJXaX+sOG4XgRSCWi/0jGZr/xlpyicQOJsbAULUCNKHdFo7BvgLvzXQg37MS/wpHCW6iwTyWFAWw7BQW9wuk554PgWodau0ybEOqGfgi3JqTLKS4NqnOaBE1cQ/8bJSq+JDv0WFk1WnPThnYUASE8f+lHYR0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=NEFRkHck; arc=none smtp.client-ip=91.218.175.83 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="NEFRkHck" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=jw+HNZ/h0ecwFOQQg0GRnVDRu6AYuC2p1m3XOQpGwWI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789961740; v=1; x=1790566540; b=NEFRkHck4lXNSnugy7+OEPJf2Tyoo/UUCSrsPNfrB40Gof84+u95J0vlWQU4UnZsw5FnNjXP jUkugXgC28cfg1TTJcVHWpXH33RUGOetzb3dKsjMhZFqgVjojRV9pUIoVdKXKalO/5IOzhuLuf1 vuboaOnK44nnrJRhZZDAnefI= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 0a6b13e55ab07a85; Mon, 21 Sep 2026 03:35:40 +0000 X-Mizu-Trace-ID: 0a6b13e55ab07a85 X-Migadu-Flow: FLOW_OUT From: Tao Cui To: tj@kernel.org, josef@toxicpanda.com, axboe@kernel.dk, hch@infradead.org Cc: cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, cui.tao@linux.dev, cuitao@kylinos.cn Subject: [PATCH v3 2/4] blk-iocost: charge zone appends as writes Date: Mon, 21 Sep 2026 11:34:51 +0800 Message-ID: <20260921033453.1912971-3-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260921033453.1912971-1-cui.tao@linux.dev> References: <20260921033453.1912971-1-cui.tao@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tao Cui Zone append is a primary write operation for zoned devices; zoned xfs and btrfs use it for data writes. It is priced at zero, so the zone append portion of zoned workloads runs outside the controller: a 1%-weight cgroup issued 16000 appends at zero cost on a zoned null_blk. Treat REQ_OP_ZONE_APPEND the same as REQ_OP_WRITE so it goes through the existing seq/rand classification and charging. Fixes: 0512a75b98f8 ("block: Introduce REQ_OP_ZONE_APPEND") Signed-off-by: Tao Cui Acked-by: Tejun Heo --- block/blk-iocost.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index 0a0352554dde..7ce68e2c2e1a 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -2565,6 +2565,7 @@ static void calc_vtime_cost_builtin(struct bio *bio, = struct ioc_gq *iocg, coef_randio =3D ioc->params.lcoefs[LCOEF_RRANDIO]; coef_page =3D ioc->params.lcoefs[LCOEF_RPAGE]; break; + case REQ_OP_ZONE_APPEND: case REQ_OP_WRITE: coef_seqio =3D ioc->params.lcoefs[LCOEF_WSEQIO]; coef_randio =3D ioc->params.lcoefs[LCOEF_WRANDIO]; --=20 2.43.0 From nobody Thu Sep 24 20:30:51 2026 Received: from mta1.migadu.com (out-129.mta1.migadu.com [95.215.58.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8CD47339395 for ; Mon, 21 Sep 2026 03:35:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.129 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789961748; cv=none; b=UmXMwFth+UhPLuPkpz2Nzvvwf2jfc/5R3tTXVY2G5W/ClDSaZKshk2t/mGhsZAzt3vQ6xQbsWk08G9d7MCF7H1R8EGZc1TAJYAG9NeYNHPKFTjWvfW/qpRfGWn5mzZyteom7Rzp6Bew3gJxor0ZbPl2D2YYqtuHq5jpqHN/fvdM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789961748; c=relaxed/simple; bh=T90yU4yQzsA33m2pyuxCSgQK5dK6cah7IeuH2VTNOwo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iQddCHi9UYYMhL8BDH4oIPdntfx7jjd74B1urReZudraGyo8zUKPgcpGEWoiKuVMGNL2Q2HeDjmqfR1vx9CRBmuhh4nB5LuEZhTnwnm6oysDFb/GoO+8WBdSn4PKAMg4M2OIt2XUfBCnxDb/QaTKmYHKUXYbzqJleOnPHsRsedY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=pj8g1oiE; arc=none smtp.client-ip=95.215.58.129 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="pj8g1oiE" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=T90yU4yQzsA33m2pyuxCSgQK5dK6cah7IeuH2VTNOwo=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789961744; v=1; x=1790566544; b=pj8g1oiE/N4ACKjmeVG+Fm3GzfmDhQvEJGg/rMqI0HugYd14zLRuwZXYKhGn1Q7qN6Sk6Hxm qzcBMI3qvohE2c1792gkNK7lOZCwz+6p2aNgcKxf0clqy4bWEPwpGSp4zYeFluicqfAHpFKzYbN 2cdmKztQkFfGDy4Ie1cMzKyg= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 5a515e88813954e3; Mon, 21 Sep 2026 03:35:44 +0000 X-Mizu-Trace-ID: 5a515e88813954e3 X-Migadu-Flow: FLOW_OUT From: Tao Cui To: tj@kernel.org, josef@toxicpanda.com, axboe@kernel.dk, hch@infradead.org Cc: cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, cui.tao@linux.dev, cuitao@kylinos.cn, Christoph Hellwig Subject: [PATCH v3 3/4] blk-iocost: account zone append completions in latency stats Date: Mon, 21 Sep 2026 11:34:52 +0800 Message-ID: <20260921033453.1912971-4-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260921033453.1912971-1-cui.tao@linux.dev> References: <20260921033453.1912971-1-cui.tao@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tao Cui ioc_rqos_done() only accounts READ and WRITE completions, so zone append completions are excluded from the latency window: the vrate feedback loop cannot see ZA-induced latency, leaving it unable to respond to device saturation caused by zone appends. Similarly, calc_size_vtime_cost_builtin() does not classify zone append as a write operation. Charging (the cost model) and feedback (the latency window) are separate mechanisms, so this is not covered by the previous patch that prices zone appends. Treat zone append as WRITE for both latency accounting and cost classification. Fixes: 0512a75b98f8 ("block: Introduce REQ_OP_ZONE_APPEND") Signed-off-by: Tao Cui Reviewed-by: Christoph Hellwig Acked-by: Tejun Heo --- block/blk-iocost.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index 7ce68e2c2e1a..ec10028249fb 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -2609,6 +2609,7 @@ static void calc_size_vtime_cost_builtin(struct reque= st *rq, struct ioc *ioc, case REQ_OP_READ: *costp =3D pages * ioc->params.lcoefs[LCOEF_RPAGE]; break; + case REQ_OP_ZONE_APPEND: case REQ_OP_WRITE: *costp =3D pages * ioc->params.lcoefs[LCOEF_WPAGE]; break; @@ -2879,6 +2880,7 @@ static void ioc_rqos_done(struct rq_qos *rqos, struct= request *rq) pidx =3D QOS_RLAT; rw =3D READ; break; + case REQ_OP_ZONE_APPEND: case REQ_OP_WRITE: pidx =3D QOS_WLAT; rw =3D WRITE; --=20 2.43.0 From nobody Thu Sep 24 20:30:51 2026 Received: from mta1.migadu.com (out-135.mta1.migadu.com [95.215.58.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 652F2314D1F for ; Mon, 21 Sep 2026 03:35:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.135 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789961752; cv=none; b=HRid4jKwIY6uHsua/VA9ZXqYBzrDsMOI7XfNm5eN0gcLjfjgRBixpQenh95mU5cR0tf0gGd+WfPOIeAo7v6oHywpwYKBkK8aOViUKEwOl1dJXFmBna5UtBGND3+QUT1QtBEjWU8m1WxNbaXTFNKBEYjUvz896c5PpvXCwE++E/c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789961752; c=relaxed/simple; bh=v0HiealU7885g0c3g+4B6E2DHNlEcOC9YbJ131S/PB0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bi41egE51aQNPQnK7mgZ01MdvZHla2QnoYGPYpzrV2JHjY7ObhLx1m8O2+pAEdzMOtce9aqvqwZ7h9hnEkA8x901yIlM7Xs3eOBNn1HExG+ranxAkoK/MlbJA7/lvEQZnOaSX/D/sCcX0aIgbu8BVPopZRw7YVRgHez/Jp/zvZ4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=g9jqXlu3; arc=none smtp.client-ip=95.215.58.135 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="g9jqXlu3" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=v0HiealU7885g0c3g+4B6E2DHNlEcOC9YbJ131S/PB0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789961749; v=1; x=1790566549; b=g9jqXlu3rvhX+iwml4Je+I12xJjNktC18AxYcerH4EcSCMOKOfdNZl6FRv9+h6zDq+8Mvrdo PWvoOWHb7khbBubbqpZbuDpCrX7dKfpZO2UO76XmZKmbhaCdYLngImK67cddg+c6godc9TsjW5u Tb49Or0rKS1kZrkkOzEdnLdU= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 9725d05abe37e048; Mon, 21 Sep 2026 03:35:49 +0000 X-Mizu-Trace-ID: 9725d05abe37e048 X-Migadu-Flow: FLOW_OUT From: Tao Cui To: tj@kernel.org, josef@toxicpanda.com, axboe@kernel.dk, hch@infradead.org Cc: cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, cui.tao@linux.dev, cuitao@kylinos.cn, Christoph Hellwig Subject: [PATCH v3 4/4] blk-iocost: fix stale comment in ioc_rqos_throttle() Date: Mon, 21 Sep 2026 11:34:53 +0800 Message-ID: <20260921033453.1912971-5-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260921033453.1912971-1-cui.tao@linux.dev> References: <20260921033453.1912971-1-cui.tao@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tao Cui The comment says that priority-inversion IOs are "punted to @ioc->aux_iocg", but no aux_iocg field ever existed in struct ioc. The comment was introduced already stale by commit da437b95db83 ("blk-iocost: grab ioc->lock for debt handling"). Update it to describe the current use_debt / iocg->abs_vdebt mechanism. Signed-off-by: Tao Cui Reviewed-by: Christoph Hellwig Acked-by: Tejun Heo --- block/blk-iocost.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index ec10028249fb..7475a4f79b97 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -2751,10 +2751,11 @@ static void ioc_rqos_throttle(struct rq_qos *rqos, = struct bio *bio) =20 /* * We're over budget. This can be handled in two ways. IOs which may - * cause priority inversions are punted to @ioc->aux_iocg and charged as - * debt. Otherwise, the issuer is blocked on @iocg->waitq. Debt handling - * requires @ioc->lock, waitq handling @iocg->waitq.lock. Determine - * whether debt handling is needed and acquire locks accordingly. + * cause priority inversions are issued regardless and charged against + * @iocg->abs_vdebt as debt. Otherwise, the issuer is blocked on + * @iocg->waitq. Debt handling requires @ioc->lock, waitq handling + * @iocg->waitq.lock. Determine whether debt handling is needed and + * acquire locks accordingly. */ use_debt =3D bio_issue_as_root_blkg(bio) || fatal_signal_pending(current); ioc_locked =3D use_debt || READ_ONCE(iocg->abs_vdebt); --=20 2.43.0