Re: [PATCHSET v2 btrfs/for-next] blkcg, btrfs: fix cgroup writeback support

[David Sterba]

On Sat, Jun 15, 2019 at 11:24:44AM -0700, Tejun Heo wrote:
> Hello,
> 
> Changes from v1[1]
> 
>   * 0001-cgroup-blkcg-Prepare-some-symbols-for-module-and-CON.patch
>     added.  It collects and adds symbol exports and dummy function def
>     to fix module and different config builds.
> 
> When writeback is executed asynchronously (e.g. for compression), bios
> are bounced to and issued by worker pool shared by all cgroups.  This
> leads to significant priority inversions when cgroup IO control is in
> use - IOs for a low priority cgroup can tie down the workers forcing
> higher priority IOs to wait behind them.
> 
> This patchset adds an bio punt mechanism to blkcg and updates btrfs to
> issue async IOs through it.  A bio tagged with REQ_CGROUP_PUNT flag is
> bounced to the asynchronous issue context of the associated blkcg on
> bio_submit().  As the bios are issued from per-blkcg work items,
> there's no concern for priority inversions and it doesn't require
> invasive changes to the filesystems.  The mechanism should be
> generally useful for IO control support across different filesystems.
> 
> This patchset contains the following 9 patches.  The first three are
> my blkcg patches to implement the needed mechanisms.  The latter five
> are Chris Mason's btrfs cleanup and update patches.  Please let me
> know how the patches should be routed.  Given that there currently
> aren't other users, it's likely the easiest to route all through btrfs
> tree.

That would be easiest so to avoid synchronization between two trees,
provided that all non-btrfs commits have acks/reviews.

However, as it's rc5, I'm not at all comfortable to add this patchset to
5.3 queue, the changes seem to be intrusive and redoing bio submission
path is something that will affect all workloads. I did quick tests on
fstests (without cgruops enabled) and this was fine, but that's the
minimum that must work. Wider range of workloads would be needed, I can
do that with mmtests, but all of that means that 5.3 is infeasible.

So this opens more possibilites regarding the patchset routing. Both
parts can go separately through their usual trees.