From nobody Thu Sep 24 17:02:01 2026 Received: from mta1.migadu.com (out-132.mta1.migadu.com [95.215.58.132]) (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 1FBAB3F0750 for ; Tue, 22 Sep 2026 04:39:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.132 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790051965; cv=none; b=VAO9wPbVTOXEVZpcUZEipv+u64BWUApeptG/4hECqw40274zivwxsjijMAePotimnhJcBcfDnh4liM31bkueAfumfhyXqBqLjDEJBVZH0HBSsmJEPkD4RpJzboA4QFGBa2DvtSjaN/B5MPmcYCVZNAq8oD6kO26hJ7VoieHroqk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790051965; c=relaxed/simple; bh=0VtSHkdHTfcdVbTtSFL1fJxXQTywihOSl1/4YTdOgnU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MWla7hg0V3C+oWYWmSXHnV0BMI6BXdARR4U5m35L59iHcDrDX0laDtBKYMVMF5j3pF2/xEqEhVTEnuv1Al6wbGh6/fbJBObUteVHGq+iBHyMSLR2V5wjq++WjLwjL/+20CJZDdW5xKR6P82zVvevFr5boSRNJsNsigVcy88DCs4= 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=X5TWm0W9; arc=none smtp.client-ip=95.215.58.132 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="X5TWm0W9" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=0VtSHkdHTfcdVbTtSFL1fJxXQTywihOSl1/4YTdOgnU=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790051957; v=1; x=1790656757; b=X5TWm0W9cm2cRdCgsHaaxsVUdBV+Cc42rS9fr0t2ofsZzvcGtubZ+t1waETf6OALmWkTmqMx ryzjLaMjooXJIHNj5rBgZdLfraVEYvSD5ls4e5Nq3ZFxroxqR4lPiRLoUe3jN/dgV2GOPO9LNpt 07tu6+0TJxwTf6HQgtYMA5nc= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id d74de2a8690f9189; Tue, 22 Sep 2026 04:39:17 +0000 X-Mizu-Trace-ID: d74de2a8690f9189 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 v4 1/4] blk-iocost: add flush cost support with the flushiops model parameter Date: Tue, 22 Sep 2026 12:38:53 +0800 Message-ID: <20260922043856.2020116-2-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260922043856.2020116-1-cui.tao@linux.dev> References: <20260922043856.2020116-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, 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 per-request policy charge: a user-tunable 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. 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 | 7 +++++++ block/blk-iocost.c | 27 +++++++++++++++++++++---- 2 files changed, 30 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-= guide/cgroup-v2.rst index 8d2603751c51..231c39d1a11a 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 maximum flushes per second =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,12 @@ 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 write with + a preceding cache flush is charged one flush on top of its data + cost, and a FUA write one more flush on devices without native + FUA support. 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..546458246cf9 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 /* @@ -2533,7 +2538,16 @@ static void calc_vtime_cost_builtin(struct bio *bio,= struct ioc_gq *iocg, u64 seek_pages =3D 0; u64 cost =3D 0; =20 - /* Can't calculate cost for empty bio */ + /* + * FUA on a device without native support becomes a post-flush; + * charge it like PREFLUSH from the flush coefficient. + */ + if (bio->bi_opf & REQ_PREFLUSH) + cost +=3D ioc->params.lcoefs[LCOEF_FLUSH]; + if ((bio->bi_opf & REQ_FUA) && !bdev_fua(bio->bi_bdev)) + cost +=3D ioc->params.lcoefs[LCOEF_FLUSH]; + + /* Can't calculate data cost for empty bio */ if (!bio->bi_iter.bi_size) goto out; =20 @@ -2708,7 +2722,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 +3456,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 +3488,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 17:02:01 2026 Received: from mta0.migadu.com (out-216.mta0.migadu.com [91.218.175.216]) (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 9DFDD3E4C6B for ; Tue, 22 Sep 2026 04:39:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.216 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790051967; cv=none; b=JkNF72wrein0d7Akq/96by3MTZhQLb2PWkKvGOLonQDzo5NMbMGXWjJuA2/5AM0l8LnE2WGZbpVTl7tUNFzkLTBLQusQNYS2MljLHnssEYyetXPvYGAm6RCW+812Ornyzoi/8IB9WVsAC2gHU0B/K69Sn1tBunuOvKGF5DyJ12M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790051967; c=relaxed/simple; bh=MTDgTZY1SVlOE7xli04ykLXBc+uQIoxK/6E0aXN7PRI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZAbXprvqIsJBQVBtciDMRWxPi+NFrFJOOGOR2xB91UBwsNSbNnybuIDAAl/+PPkdtjy8wcAoPKfuARMxxhb3icFjZZS1C0E8wqNg17cuCdjlZbl1xWhwviLaTV5w/HABx/sNgaBBqAB7bzGP5I9Uzgd9YqULKyAFHLgTSlWZtp0= 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=LlgAkq3B; arc=none smtp.client-ip=91.218.175.216 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="LlgAkq3B" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=MTDgTZY1SVlOE7xli04ykLXBc+uQIoxK/6E0aXN7PRI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790051960; v=1; x=1790656760; b=LlgAkq3By8yRC3M38mz2liE+JHsH0AS8FsppRsAV6MVcIb/SwzWdHfX9zi3DaS0fcO+x09U+ BFuZiliTI/VCPgyhVtmOmwhJWNQvXaQa74EL23+pqQbVEZ1prvu0TCWVRng33O+hjqPxZJlWHZZ MHO3oz5WMFxCCKpLq2IPeyDU= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id f7e9b12a9d775cde; Tue, 22 Sep 2026 04:39:20 +0000 X-Mizu-Trace-ID: f7e9b12a9d775cde 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 v4 2/4] blk-iocost: charge zone appends as writes Date: Tue, 22 Sep 2026 12:38:54 +0800 Message-ID: <20260922043856.2020116-3-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260922043856.2020116-1-cui.tao@linux.dev> References: <20260922043856.2020116-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 546458246cf9..6b262ccb6b32 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -2557,6 +2557,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 17:02:01 2026 Received: from mta0.migadu.com (out-222.mta0.migadu.com [91.218.175.222]) (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 9ED4A3F1640 for ; Tue, 22 Sep 2026 04:39:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.222 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790051975; cv=none; b=HuImBNs16TGyXYPuld5LMsUs9CGPrRTrq0kADZz3O2162xLSgYT60U3Be216qJnjAYTxhOLcao2tSY+TGq/x+KjJnGKd4GF6J0XeUnkOW5xabRbVcaATC17xcNFyg9AA22CVF8y2ilQR5foTz80ZoEkM/58+FqpYmlo8diOi55s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790051975; c=relaxed/simple; bh=jkQ9YMPODGMTgKGwx8hfh8F2ew/NT3cs1OijQlA8Ws8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qMtR3lo6oGRclj5T9k4sN8CNIwzTfaYBjubJQNLaxRYor4VRV6gM8ubQMECopCcPQtRfgB45MCpTz4SqOcVMzEBci6WwZQGH3TPNne4dTSyxMxlCchCtY0YDjVW7EPWQPQXuhyYeMmYEzYx0unvnbEj8+OeC0jHw2NThOuhXwFM= 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=fegZSm7C; arc=none smtp.client-ip=91.218.175.222 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="fegZSm7C" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=jkQ9YMPODGMTgKGwx8hfh8F2ew/NT3cs1OijQlA8Ws8=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790051965; v=1; x=1790656765; b=fegZSm7CM/hIS0JNr4labss0EtG/uPvtPkHgOCyH/a6KNMth9FN9pzzPYxTf1Zvz5Yeow89D J/IVLc4cWet7C+mjqUyG8Jzw1kRvRWkJeq5gn3aO6llBKoazecYK53183WRosbFGJF1juxCnf9C lGsUNfyMMKJNQThw93yXc/sE= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 1f5cc8b9c7f2cd4b; Tue, 22 Sep 2026 04:39:25 +0000 X-Mizu-Trace-ID: 1f5cc8b9c7f2cd4b 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 v4 3/4] blk-iocost: account zone append completions in latency stats Date: Tue, 22 Sep 2026 12:38:55 +0800 Message-ID: <20260922043856.2020116-4-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260922043856.2020116-1-cui.tao@linux.dev> References: <20260922043856.2020116-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 6b262ccb6b32..9ca58cfbce86 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -2601,6 +2601,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; @@ -2871,6 +2872,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 17:02:01 2026 Received: from mta1.migadu.com (out-145.mta1.migadu.com [95.215.58.145]) (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 5CDD43596F8 for ; Tue, 22 Sep 2026 04:39:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.145 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790051982; cv=none; b=Tj9eQ/BovHOYShRAYupxgcsChxVoaGg1yIj8LdIGjoiN8agZXkPmG47AX9TUdM/Mnz5GPxDEsKWHndbeLLNQC64qJPqcux4t5eBPtg+34HeLkQ6UGP1ii0maOo2baLJKTp2X8urciTA4/wB8Z8b6U7Xp8wC1K+SqKYqHyMENy/A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790051982; c=relaxed/simple; bh=bXbEK/PiziSTn08RAdNdo/eKnwYk983TIRsyonb/wYU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aCmFkxWh9wlD/r79rhP2ggC83h3rrsonCvGXogLgrP2iCWH1nSB9/ScC9NeD7bHiV3HaZlJdn5O5rZeiqFlLSPQcU+67lXl+851Sf3ZGMnHx27ag+62Ck83zlvwhquKe7hNGOM8tTgujGoXHeGTFkGVoQswW/v2Py2eK+E9uC7Q= 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=U/MCce+c; arc=none smtp.client-ip=95.215.58.145 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="U/MCce+c" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=bXbEK/PiziSTn08RAdNdo/eKnwYk983TIRsyonb/wYU=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790051974; v=1; x=1790656774; b=U/MCce+cvi5fr37Oa/MzgQQoiX8ooYC5HJ+GEXD17Sx07+JtAJQ8K16ra3tkNy4bz36Y6hGN WD7Vs3NX89a7+Cbk/On7w96koBsIJyj1rBQcCLeFzen0oapHGzHrNyGIs06gtbyE95oJW0H4LUQ mAU8DWwEK22UyhMDR56UYQ1A= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 04fdd75e5b702cb4; Tue, 22 Sep 2026 04:39:34 +0000 X-Mizu-Trace-ID: 04fdd75e5b702cb4 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 v4 4/4] blk-iocost: fix stale comment in ioc_rqos_throttle() Date: Tue, 22 Sep 2026 12:38:56 +0800 Message-ID: <20260922043856.2020116-5-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260922043856.2020116-1-cui.tao@linux.dev> References: <20260922043856.2020116-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 9ca58cfbce86..a81488c755ca 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -2743,10 +2743,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