All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dennis Zhou <dennis@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-block@vger.kernel.org, tj@kernel.org, dm-devel@redhat.com,
	Mike Snitzer <snitzer@kernel.org>,
	axboe@kernel.dk
Subject: Re: [dm-devel] [PATCH] block: remove redundant blk-cgroup init from __bio_clone
Date: Tue, 12 Apr 2022 00:52:13 -0700	[thread overview]
Message-ID: <YlUvrXX2M3VqsgCQ@fedora> (raw)
In-Reply-To: <YlUN2pVsIn1dbzHg@infradead.org>

On Mon, Apr 11, 2022 at 10:27:54PM -0700, Christoph Hellwig wrote:
> On Mon, Apr 11, 2022 at 01:33:58PM -0400, Mike Snitzer wrote:
> > When bio_{alloc,init}_clone are passed a bdev, bio_init() will call
> > bio_associate_blkg() so the __bio_clone() work to initialize blkcg
> > isn't needed.
> 
> No, unfortunately it isn't as simple as that.  There are bios that do
> not use the default cgroup and thus blkg, e.g. those that come from
> cgroup writeback.

Yeah I wasn't quite right earlier. But, the new api isn't in line with
the original semantics. Cloning the blkg preserves the original bios
request_queue which likely differs from the bdev passed into clone. This
means an IO might be charged to the wrong device.

So, the blkg combines the who, blkcg, and the where, the corresponding
request_queue. Before bios were inited in 2 phases:
    bio_alloc();
    bio_set_dev();

This meant at clone time, we didn't have the where, but the who was
encased in the blkg. So, after bio_clone_blkg_association() expected a
bio_set_dev() call which called bio_associate_blkg(). When the bio
already has a blkg, it attempts to reuse the blkcg while using the new
bdev to find the correct blkg.

The tricky part seems to be how to seamlessly expose the appropriate
blkcg without being intrusive to bio_alloc*() apis.

Regarding the NULL bdev, I think that works as long as we keep the
bio_clone_blkg_association() call to carry the correct blkcg to the
bio_set_dev() call.

Thanks,
Dennis

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


WARNING: multiple messages have this Message-ID (diff)
From: Dennis Zhou <dennis@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Mike Snitzer <snitzer@kernel.org>,
	linux-block@vger.kernel.org, tj@kernel.org, axboe@kernel.dk,
	dm-devel@redhat.com
Subject: Re: [PATCH] block: remove redundant blk-cgroup init from __bio_clone
Date: Tue, 12 Apr 2022 00:52:13 -0700	[thread overview]
Message-ID: <YlUvrXX2M3VqsgCQ@fedora> (raw)
In-Reply-To: <YlUN2pVsIn1dbzHg@infradead.org>

On Mon, Apr 11, 2022 at 10:27:54PM -0700, Christoph Hellwig wrote:
> On Mon, Apr 11, 2022 at 01:33:58PM -0400, Mike Snitzer wrote:
> > When bio_{alloc,init}_clone are passed a bdev, bio_init() will call
> > bio_associate_blkg() so the __bio_clone() work to initialize blkcg
> > isn't needed.
> 
> No, unfortunately it isn't as simple as that.  There are bios that do
> not use the default cgroup and thus blkg, e.g. those that come from
> cgroup writeback.

Yeah I wasn't quite right earlier. But, the new api isn't in line with
the original semantics. Cloning the blkg preserves the original bios
request_queue which likely differs from the bdev passed into clone. This
means an IO might be charged to the wrong device.

So, the blkg combines the who, blkcg, and the where, the corresponding
request_queue. Before bios were inited in 2 phases:
    bio_alloc();
    bio_set_dev();

This meant at clone time, we didn't have the where, but the who was
encased in the blkg. So, after bio_clone_blkg_association() expected a
bio_set_dev() call which called bio_associate_blkg(). When the bio
already has a blkg, it attempts to reuse the blkcg while using the new
bdev to find the correct blkg.

The tricky part seems to be how to seamlessly expose the appropriate
blkcg without being intrusive to bio_alloc*() apis.

Regarding the NULL bdev, I think that works as long as we keep the
bio_clone_blkg_association() call to carry the correct blkcg to the
bio_set_dev() call.

Thanks,
Dennis

  reply	other threads:[~2022-04-12  7:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 16:52 can we reduce bio_set_dev overhead due to bio_associate_blkg? Mike Snitzer
2022-03-30 16:52 ` [dm-devel] " Mike Snitzer
2022-03-30 12:28 ` Dennis Zhou
2022-03-30 12:28   ` [dm-devel] " Dennis Zhou
2022-03-31  4:39   ` Christoph Hellwig
2022-03-31  4:39     ` [dm-devel] " Christoph Hellwig
2022-03-31  5:52     ` Dennis Zhou
2022-03-31  5:52       ` [dm-devel] " Dennis Zhou
2022-03-31  9:15       ` Christoph Hellwig
2022-03-31  9:15         ` [dm-devel] " Christoph Hellwig
2022-04-08 15:42         ` Mike Snitzer
2022-04-08 15:42           ` [dm-devel] " Mike Snitzer
2022-04-09  5:15           ` Christoph Hellwig
2022-04-09  5:15             ` [dm-devel] " Christoph Hellwig
2022-04-11 16:58             ` Mike Snitzer
2022-04-11 16:58               ` [dm-devel] " Mike Snitzer
2022-04-11 17:16               ` Mike Snitzer
2022-04-11 17:16                 ` [dm-devel] " Mike Snitzer
2022-04-11 17:33                 ` [PATCH] block: remove redundant blk-cgroup init from __bio_clone Mike Snitzer
2022-04-11 17:33                   ` [dm-devel] " Mike Snitzer
2022-04-12  5:27                   ` Christoph Hellwig
2022-04-12  5:27                     ` [dm-devel] " Christoph Hellwig
2022-04-12  7:52                     ` Dennis Zhou [this message]
2022-04-12  7:52                       ` Dennis Zhou
2022-04-23 16:55                   ` Christoph Hellwig
2022-04-23 16:55                     ` [dm-devel] " Christoph Hellwig
2022-04-26 17:30                     ` Mike Snitzer
2022-04-26 17:30                       ` [dm-devel] " Mike Snitzer

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=YlUvrXX2M3VqsgCQ@fedora \
    --to=dennis@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=snitzer@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.