Re: can we reduce bio_set_dev overhead due to bio_associate_blkg?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 30, 2022 at 08:28:28AM -0400, Dennis Zhou wrote:
> I think cloning is a special case that I might have gotten wrong. If
> there is a bio_set_dev() call after each clone(), then the
> bio_clone_blkg_association() is excess work. We'd need to audit how
> bio_alloc_clone() is being used to be safe. Alternatively, we could opt
> for a bio_alloc_clone_noblkg(), but that's a little bit uglier.

As of Linux 5.18, the cloning interfaces have changed and take
a block devie that the clone is intended to be used for, and bio_set_dev
is mostly (there is a few more sports to be cleaned up in
dm/md/bcache/btrfs) only used for remapping to a new device.

That being said I've eyed the code in bio_associate_blkg a bit and
I've been wondering about some of how it is implemented as well.

Is recursive throttling really a thing?  i.e. we can have cgroup
policies on the upper (e.g. dm) device and then again on the lower
(e.g. nvme device)?  I think the code currently supports that, and
if we want to keep that I don't really see much of a way to avoid
the lookup, but maybe we cn make it faster.

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




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux