All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Cui <cui.tao@linux.dev>
To: Tejun Heo <tj@kernel.org>
Cc: cui.tao@linux.dev, 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 16:09:57 +0800	[thread overview]
Message-ID: <acd79732-1ef3-47d5-96fc-4dd3ff3eee27@linux.dev> (raw)
In-Reply-To: <arFgjkKUwYGWbV8H@slm.duckdns.org>

Hi Tejun,

在 2026/9/22 00:51, Tejun Heo 写道:
> On Mon, Sep 21, 2026 at 03:06:47PM +0800, Tao Cui wrote:
>> From: Tao Cui <cuitao@kylinos.cn>
>>
>> Passthrough requests (SG_IO, bsg, nvme passthrough ioctls and uring
>> commands) are dispatched via blk_execute_rq{,_nowait}() without ever
>> passing through submit_bio(), so the bio mapped by blk_rq_map_user()
>> carries no blkcg association: the transferred bytes never show up in
>> cgroup io.stat, and every rq_qos policy on the queue (iocost,
>> iolatency, wbt) is bypassed, as is blk-throttle, which hooks
>> submit_bio_noacct() directly rather than going through rq_qos.
>>
>> A quick demonstration on a scsi_debug device with iocost enabled and
>> vrate pinned to its 1% floor: a direct fio writer was throttled ~10x
>> while the same cgroup issuing sg_dd writes ran at full device speed
>> with zero io.stat accounting.
>>
>> Associate the mapped bio with the submitter's blkcg at dispatch time
>> and run the regular bio accounting (blk_cgroup_bio_start()) and
>> rq_qos throttle paths with it.  DRV_IN/DRV_OUT commands are mapped to
>> READ/WRITE so io.stat classifies their bytes normally; request
>> completion already pairs with the throttle through bio_endio() ->
>> rq_qos_done_bio().
>>
>> The charge is gated by opcode (READ/WRITE/DRV_IN/DRV_OUT) and to
>> queues that already have a gendisk: commands issued during device
>> probing (SCSI INQUIRY etc.) have no gendisk yet and stay exempt,
>> following the same probe-exemption reasoning as the passthrough
>> iostats support.
> 
> Do you have an actual use case where this matters?
> 

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.

Thanks,
Tao

> Thanks.
> 



  reply	other threads:[~2026-09-22  8:10 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 [this message]
2026-09-22 15:53       ` Tejun Heo
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=acd79732-1ef3-47d5-96fc-4dd3ff3eee27@linux.dev \
    --to=cui.tao@linux.dev \
    --cc=axboe@kernel.dk \
    --cc=cgroups@vger.kernel.org \
    --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=tj@kernel.org \
    --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.