From: Jialin Wang <wjl.linux@gmail.com>
To: wjl.linux@gmail.com
Cc: axboe@kernel.dk, cgroups@vger.kernel.org, josef@toxicpanda.com,
lianux.mm@gmail.com, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, tj@kernel.org
Subject: Re: [RFC PATCH] blk-iocost: introduce 'linear-max' cost model for cloud disk
Date: Fri, 13 Feb 2026 20:01:47 +0800 [thread overview]
Message-ID: <20260213120147.322797-1-wjl.linux@gmail.com> (raw)
In-Reply-To: <20260213094218.253536-1-wjl.linux@gmail.com>
On Fri, Feb 13, 2026 at 5:42 PM Jialin Wang <wjl.linux@gmail.com> wrote:
> > This formula correctly models the dual-bucket behavior of cloud disks.
> > It ensures that for any block size, the calculated cost aligns with the
> > actual bottleneck (IOPS or BPS). This allows the system to reach close
> > to the provisioned BPS/IOPS limits without premature throttling, while
> > still maintaining the latency protection benefits of iocost.
>
> This model still has some limitations. Under workloads with mixed IO sizes and
> vrate max at 100%, it fail to fully saturate the hardware performance.
> However, it still demonstrates a clear improvement over the linear model.
>
> The following fio benchmarks were conducted with two cgroups assigned equal weights:
>
> Cgroup A: fio --bs=32k ...
> Cgroup B: fio --bs=1M ...
>
> Results:
>
> Model | Cgroup A (32k) | Cgroup B (1M) | Total
> ------------+------------------------+----------------------|----------------------
> linear | 1137 IOPS (35.5 MiB/s) | 79 IOPS (79.5 MiB/s) | 1216 IOPS 115.0 MiB/s
> linear-max | 1781 IOPS (55.7 MiB/s) | 83 IOPS (83.9 MiB/s) | 1864 IOPS 139.6 MiB/s
One potential long-term solution might be to separate the accounting for IOPS
and BPS. By tracking two independent vtime counters (vtime_ios and vtime_bytes)
with their own weights, we could apply throttling based on the specific
resource being consumed. This would avoid cases where high-bandwidth requests
unnecessarily eat up the IOPS budget, and vice versa. I would love to hear your
thoughts on this idea. Is this a direction worth exploring, or would the added
complexity be a concern?
Thanks,
Jialin Wang
next prev parent reply other threads:[~2026-02-13 12:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 7:38 [RFC PATCH] blk-iocost: introduce 'linear-max' cost model for cloud disk Jialin Wang
2026-02-13 9:42 ` Jialin Wang
2026-02-13 12:01 ` Jialin Wang [this message]
2026-02-13 12:14 ` Yu Kuai
2026-02-13 12:24 ` Jialin Wang
2026-02-13 16:54 ` Yu Kuai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260213120147.322797-1-wjl.linux@gmail.com \
--to=wjl.linux@gmail.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=josef@toxicpanda.com \
--cc=lianux.mm@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.