From nobody Fri Sep 25 06:02:54 2026 Received: from mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) (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 B8898314D37 for ; Wed, 16 Sep 2026 08:53:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789548808; cv=none; b=kbSxDuw0nzsWxo73i3Z7HNDSzn4KEVZnZ1JBiDzSUnz4nKU2dcpun2hfIZE163x/aXc07xuWMMZPc4tvVhph9leTQ7deMvAdJbsqGiMXsnGOpW+Viu8vgLxZ+kdLhtPeDWBUbn4EP3ANuv+M1gWQq0xkyc/cUlAqFYRPuJkaeFQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789548808; c=relaxed/simple; bh=fdL14IAAyspEhi0GV5wFbcG5ftrEbuX893CxOZt28EQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=A+6d9ta4zpVsVApZS/tLZj/MMNRIIwub+g1/JcGbT2/Hl+wlRNhqqgv2CDsV7ZbAtaF6tT28ECpYQbQrQFi1WzjAnnphgQ1q8y3h2zF1sYOy/5r7WvE7Flwa68rEvGkKrIDS/QmTj+coonNovRwkzjE63as397Vy1xBYRWBE9q0= 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=rJjskVak; arc=none smtp.client-ip=91.218.175.181 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="rJjskVak" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=fdL14IAAyspEhi0GV5wFbcG5ftrEbuX893CxOZt28EQ=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789548799; v=1; x=1790153599; b=rJjskVaksFI6BVZw8GRHy8W9KY1hRiz3xucG6/nGugfQeNcWtrDMAYN+SkceJkhxWHyEXYip GMZFjXr9+Ynmm3RQRLgUUxoPRfZDW48HbT0EzGhBmOzJs47vurdC4CJlBK5/858PC4xmi7DjTi9 vPQgqSMfzN3A8UORn5wbwiA8= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id cb84e947b6f73556; Wed, 16 Sep 2026 08:53:19 +0000 X-Mizu-Trace-ID: cb84e947b6f73556 X-Migadu-Flow: FLOW_OUT From: Tao Cui To: tj@kernel.org, josef@toxicopanda.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 v2 1/4] blk-iocost: charge flushes as pageless random writes Date: Wed, 16 Sep 2026 16:53:01 +0800 Message-ID: <20260916085304.1080271-2-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916085304.1080271-1-cui.tao@linux.dev> References: <20260916085304.1080271-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 Standalone flushes issued by blkdev_issue_flush() are represented as dataless REQ_OP_WRITE | REQ_PREFLUSH bios, which calc_vtime_cost_builtin() prices at zero. The flush component of flush-heavy workloads such as database commits, journal flushes, and metadata sync is thus neither charged nor throttled: a cgroup at 1% weight can issue ~510k flushes per 12s, monopolizing the device while iocost reports zero usage. The same is true for the flush component of data-bearing REQ_OP_WRITE | REQ_PREFLUSH bios, e.g. journal commit writes: they are charged for their data only, and the cache flush the flush machine runs ahead of it is free. Charge the flush component of any REQ_PREFLUSH bio on top of its data cost, priced as a pageless random write (LCOEF_WRANDIO), which provides an approximation of the device time consumed by a flush. For profiles where WRANDIO clamps to zero (ssd_dfl / ssd_fast), use a one-page floor (LCOEF_WPAGE). A dataless flush bio falls out of the switch with zero data cost and picks up the same surcharge, so standalone and pre-flush forms are priced the same way. After this patch, the same 1%-weight cgroup is limited to 24 flushes per 12s; on ext4, write+fsync workloads are correctly accounted through the journal layer (~2.2us per flush on the ssd_fast profile). A standalone flush must also not update iocg->cursor: its bi_sector (usually 0) is not a data position, so setting the cursor from it would misclassify the following READ/WRITE bios, and a zero cursor defeats the !iocg->cursor sentinel in calc_vtime_cost_builtin(). Skip the cursor update for dataless bios. Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Signed-off-by: Tao Cui Reviewed-by: Christoph Hellwig --- Changes in v2: - Skip the iocg->cursor update for dataless flush bios, which would otherwise corrupt the seq/rand classification of the following IOs (reported in review of v1). - Charge the flush component of data-bearing REQ_PREFLUSH bios too; v1 only priced standalone flushes (reported in review of v1). --- block/blk-iocost.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index 2745bffcd5eef..082f26d6e27b6 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -2532,8 +2532,20 @@ 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; =20 - /* Can't calculate cost for empty bio */ + /* + * A WRITE|REQ_PREFLUSH bio carries a flush component: the flush + * machine runs a cache flush for it, either standalone (dataless) + * or ahead of the data. Charge the flush on top of the data cost, + * priced as a pageless random write with a one-page floor so fast + * profiles still charge something. Flush bios are never merged. + */ + if (!is_merge && (bio->bi_opf & REQ_PREFLUSH)) + flush_cost =3D max(ioc->params.lcoefs[LCOEF_WRANDIO], + ioc->params.lcoefs[LCOEF_WPAGE]); + + /* Can't calculate data cost for empty bio */ if (!bio->bi_iter.bi_size) goto out; =20 @@ -2566,7 +2578,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 +2720,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 --=20 2.43.0 From nobody Fri Sep 25 06:02:54 2026 Received: from mta0.migadu.com (out-194.mta0.migadu.com [91.218.175.194]) (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 02A0C480974 for ; Wed, 16 Sep 2026 08:53:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.194 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789548815; cv=none; b=LQOl2ypp5d1wgKLuh+hzxAu2r0YfgovIgaO1BiZ0TJHgdm1ibRlLizryWrRR00CUDZmLU584FAV0OMYYf2ekTM6hWlTGVNKIKeUfuHdU5gl8mHolpdUPdHbX+CPzSBd/vImS4F0Qty4zLzhVGYUVOGgui+3QDWybIu/jEYy0f8E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789548815; c=relaxed/simple; bh=loa/g3I+Yv/9naA0zXCKsZcRV0ZjLJKQ5OTetC/5DVw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FZI5owhNq2PatizMOOiim735NSxwHBJAQ7qJHP562J9fugI0XK5KvH63OEFkJgVyj1QJFTqBjuvP4wTxCx5aF5liVAyXyxDFCl5ZZDDIlr0VD0doREI4MfwbqwADtCggiyNJnU50WGBudlpBXJnRi7JZcou8lEDBeJ0+jZvkv44= 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=BuiPTh5I; arc=none smtp.client-ip=91.218.175.194 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="BuiPTh5I" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=loa/g3I+Yv/9naA0zXCKsZcRV0ZjLJKQ5OTetC/5DVw=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789548806; v=1; x=1790153606; b=BuiPTh5I0jkUZb7q+SDPnksxAfJtDS9QplS6jrlObT9ZRyRG3SWNgjk7aaOIbQHTshtCwWlZ m1mxjceUwfDj0lj1PPGgpHoxKwJvofGaytDAwlgnVNojUAMlhGV98mQ5YZ9Ryat2BOMV5Gbqybj xpi0ZHb51mLDRn5N5NmGGVes= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id adf49a5116c396e5; Wed, 16 Sep 2026 08:53:26 +0000 X-Mizu-Trace-ID: adf49a5116c396e5 X-Migadu-Flow: FLOW_OUT From: Tao Cui To: tj@kernel.org, josef@toxicopanda.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 v2 2/4] blk-iocost: charge zone appends as page-counted sequential writes Date: Wed, 16 Sep 2026 16:53:02 +0800 Message-ID: <20260916085304.1080271-3-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916085304.1080271-1-cui.tao@linux.dev> References: <20260916085304.1080271-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 btrfs and f2fs 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. A zone append advances the zone write pointer and is therefore sequential from the device's perspective; the actual sector is only returned after completion, so the cursor-based seq/rand classification doesn't apply. Price it as a page-counted sequential write. After this patch, 16000 appends from the same cgroup are charged 533264 usec (33us per append). Also skip the cursor update for ZA bios: bi_sector is the zone start, not the actual write position (which is only returned after completion). Setting the cursor from ZA would misclassify subsequent READ/WRITE bios. Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Signed-off-by: Tao Cui Reviewed-by: Christoph Hellwig --- block/blk-iocost.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index 082f26d6e27b6..2e4e9ce2c9359 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -2560,6 +2560,17 @@ static void calc_vtime_cost_builtin(struct bio *bio,= struct ioc_gq *iocg, coef_randio =3D ioc->params.lcoefs[LCOEF_WRANDIO]; coef_page =3D ioc->params.lcoefs[LCOEF_WPAGE]; break; + case REQ_OP_ZONE_APPEND: + /* + * A zone append advances the zone write pointer and is + * therefore sequential from the device's perspective, so + * the cursor-based classification below doesn't apply. + * Compute the full cost here. + */ + if (!is_merge) + cost +=3D ioc->params.lcoefs[LCOEF_WSEQIO]; + cost +=3D pages * ioc->params.lcoefs[LCOEF_WPAGE]; + goto out; default: goto out; } @@ -2720,8 +2731,8 @@ static void ioc_rqos_throttle(struct rq_qos *rqos, st= ruct bio *bio) if (!iocg_activate(iocg, &now)) return; =20 - /* dataless bios have no meaningful position for seq/rand detection */ - if (bio->bi_iter.bi_size) + /* ZA bi_sector is zone start, dataless bios have no write position */ + if (bio->bi_iter.bi_size && bio_op(bio) !=3D REQ_OP_ZONE_APPEND) 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 2.43.0 From nobody Fri Sep 25 06:02:54 2026 Received: from mta0.migadu.com (out-205.mta0.migadu.com [91.218.175.205]) (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 C4AFB4854E5 for ; Wed, 16 Sep 2026 08:53:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.205 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789548830; cv=none; b=nYNTgWpYB5/hP4qW5CDcSl28CbAnBperkVA25p3peRK9UF6LM8w0paB7JGiy7BPyN3LEtMTb24qk8Aw/ij2sM38mFmLFHSxOTyZeoio1PYBsv8wTREkEJwoRiW4m6AVPORvoDpWKYjiDZEAkb+0NSJYHEdNPxm6RAE6Y89ruEBg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789548830; c=relaxed/simple; bh=kCLIOKC5wMvDVR07yq/o4W7NDVvGkZvtFSaE4nzjdqU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pjZDc2U5m+69qA6Aj61Kj781VPgrWVqAXzdnCRKBJCWwgTzLH/6jbHBHFpAi1YoYBoAwqLk8qzd+Fjir4cjZ0li7V5CFgsTDzvG47VYXv7no24ddq4bKUFEAKdgcUuVfPMmvbcd/mLZB6Li/S10cGjgAuvC/0BJNAZt09oclCVA= 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=f/EAGotJ; arc=none smtp.client-ip=91.218.175.205 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="f/EAGotJ" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=kCLIOKC5wMvDVR07yq/o4W7NDVvGkZvtFSaE4nzjdqU=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789548813; v=1; x=1790153613; b=f/EAGotJivNnLMAsqHzWgdw5Ifv8zRv5DVXNFDwebnGbRRVADz3IopW1v1v8CT4rMM/YvUz4 H+kQ9iSvTHDO6U9OKPomSdK8g+8XIGCfrjAVyRqwqFYVk0EtM6iwFA3pKF8o03qtmLGDvqG6NdF XncWDJkd2mh5nOvE0i0LGP38= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 918a633a8f8616b2; Wed, 16 Sep 2026 08:53:33 +0000 X-Mizu-Trace-ID: 918a633a8f8616b2 X-Migadu-Flow: FLOW_OUT From: Tao Cui To: tj@kernel.org, josef@toxicopanda.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 v2 3/4] blk-iocost: account zone append completions in latency stats Date: Wed, 16 Sep 2026 16:53:03 +0800 Message-ID: <20260916085304.1080271-4-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916085304.1080271-1-cui.tao@linux.dev> References: <20260916085304.1080271-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. This is not covered by the patch that prices zone appends: charging goes through the cost model, while the latency window is the feedback path the vrate controller watches. Treat zone append as WRITE for both latency accounting and cost classification. Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Signed-off-by: Tao Cui Reviewed-by: Christoph Hellwig --- block/blk-iocost.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index 2e4e9ce2c9359..ef1b7e65455e2 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 Fri Sep 25 06:02:54 2026 Received: from mta0.migadu.com (out-212.mta0.migadu.com [91.218.175.212]) (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 00744485CC8 for ; Wed, 16 Sep 2026 08:53:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.212 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789548826; cv=none; b=XkGC7tw8WtKBTO0rUUDSsTl7FEs+8twIKFc6e0CwEUpqMWqlqrF2wyzfSOPB9/sfXc+3Lp444Jrdeyq0cJBySJUy9Iz5RIzn/mU28Ds0QCfwWnunX+rb6PFGI+n2ReP0oF7yxVLHgeWyaTapd5/GFGxF8OIJaGwEw8y84KsCUWU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789548826; c=relaxed/simple; bh=L3Cao1O+/S3bUdRzlg80CCgGlmroX8RaAQqh5IyZWk4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LWLQFoOL0ZJfK6YEgVBblcUnqPhLEnY6mxwdcSQd4rysfi0h/1/HAK8ezPzXC2eQd0FNgB7NM0Mj6VlrrdUccw+0uWyRioSszmtgG/mWAN+ZhpG+6e7yLTXb0T1R+iK/lEHFmA9EtZtY+u+Ka1C5t/YhqjNLjOKqzalEvc+L1CM= 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=dWtWWgCI; arc=none smtp.client-ip=91.218.175.212 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="dWtWWgCI" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=L3Cao1O+/S3bUdRzlg80CCgGlmroX8RaAQqh5IyZWk4=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789548816; v=1; x=1790153616; b=dWtWWgCINz5BryUE401GIE/naHiNICqAlIjc/7SVlZdrRYs4o/mP/J7lxA0SMvVi2iejLmEI pyPAdCB7vPDPebYXJLWnOJyDPDUvJiivN70Y00GsCG2G3dYTU1UlyVFfGBovsX1k7yVCoWvk4S0 +nZoXr2ioaD9SWH7X2jIvohU= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id b436a119b2c988d9; Wed, 16 Sep 2026 08:53:36 +0000 X-Mizu-Trace-ID: b436a119b2c988d9 X-Migadu-Flow: FLOW_OUT From: Tao Cui To: tj@kernel.org, josef@toxicopanda.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 v2 4/4] blk-iocost: fix stale comment in ioc_rqos_throttle() Date: Wed, 16 Sep 2026 16:53:04 +0800 Message-ID: <20260916085304.1080271-5-cui.tao@linux.dev> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916085304.1080271-1-cui.tao@linux.dev> References: <20260916085304.1080271-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 --- 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 ef1b7e65455e2..0a0821a080043 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