From: Tejun Heo <tj@kernel.org>
To: Tao Cui <cui.tao@linux.dev>
Cc: axboe@kernel.dk, kbusch@kernel.org, hch@lst.de, sagi@grimberg.me,
yukuai@fygo.io, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, cuitao@kylinos.cn
Subject: Re: [RFC PATCH 1/1] block: charge passthrough requests to the submitter's cgroup
Date: Tue, 22 Sep 2026 05:53:24 -1000 [thread overview]
Message-ID: <arKkdCkRGilTypb7@slm.duckdns.org> (raw)
In-Reply-To: <acd79732-1ef3-47d5-96fc-4dd3ff3eee27@linux.dev>
Hello,
On Tue, Sep 22, 2026 at 04:09:57PM +0800, Tao Cui wrote:
> I don't have a specific passthrough workload that triggered this in
> production. I ran into it while testing blk-iocost accounting coverage.
>
> The relevant concern here is cgroup IO isolation. The expectation of
> blkcg IO control is that the IO consumed by a cgroup is reflected in its
> accounting and subject to blkcg IO policies. Today that is true for IO
> going through submit_bio(), but not for passthrough requests.
>
> The concrete observation was that the same cgroup issuing equivalent
> writes through two paths gets different results: normal bio IO is
> accounted in io.stat and subject to blkcg IO policies, while SG_IO
> writes consume device bandwidth without accounting or blkcg IO control.
>
> So the motivation is not a particular SG_IO application, but whether
> passthrough IO should be considered part of the IO usage controlled by
> blkcg.
>
> I don't know yet whether the right answer is always-on behavior or an
> opt-in mechanism. The RFC was mainly to discuss whether passthrough
> paths should be covered by blkcg accounting/enforcement at all.
SG_IO requires CAP_RAW_IO, so any kind of isolation isn't gonna work out
that well. This is an imaginary use case. Please stop until it become an
actual one.
Thanks.
--
tejun
next prev parent reply other threads:[~2026-09-22 15:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 7:06 [RFC PATCH 0/1] block: charge passthrough requests to the submitter's cgroup Tao Cui
2026-09-21 7:06 ` [RFC PATCH 1/1] " Tao Cui
2026-09-21 16:51 ` Tejun Heo
2026-09-22 8:09 ` Tao Cui
2026-09-22 15:53 ` Tejun Heo [this message]
2026-09-21 7:27 ` [RFC PATCH 0/1] " Tao Cui
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=arKkdCkRGilTypb7@slm.duckdns.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=cui.tao@linux.dev \
--cc=cuitao@kylinos.cn \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=yukuai@fygo.io \
/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.