Re: [PATCH block-5.14] Revert "block/mq-deadline: Add cgroup support"

[Tejun Heo <tj@kernel.org>]

On Wed, Aug 11, 2021 at 01:22:20PM -0700, Bart Van Assche wrote:
> On 8/11/21 12:14 PM, Tejun Heo wrote:
> > On Wed, Aug 11, 2021 at 11:49:10AM -0700, Bart Van Assche wrote:
> > > You write that this isn't the right way to collect per cgroup stats. What is
> > > the "right way"? Has this been documented somewhere?
> > 
> > Well, there's nothing specific to mq-deadline or any other elevator or
> > controller about the stats that your patch collected and showed. That
> > seems like a pretty straight forward sign that it likely doens't
> > belong there.
> 
> Do you perhaps want these statistics to be reported via read-only cgroup
> attributes of a new cgroup policy that is independent of any particular I/O
> scheduler?

There's an almost fundamental conflict between ioprio and cgroup IO
control. bfq layers it so that ioprio classes define the global
priority above weights and then ioprio modifies the weights within
each class. mq-deadline isn't cgroup aware and who knows what kind of
priority inversions it's creating when its ioprio enforcement is
interacting with other cgroup controllers.

The problem is that as currently used, they're specifying the same
things - how IO should be distributed globally in the system, and
there's no right way to make the two configuration configuration
regimes agree on what should happen on the system.

I can see two paths forward:

1. Accept that ioprio isn't something which makes senes with cgroup IO
   control in a generic manner and approach it in per-configuration
   manner, either by doing whatever the specific combination decided
   to do with ioprio or ignoring it.

2. The only generic way to integrate ioprio and cgroup IO control
   would be nesting ioprio inside cgroup IO control, so that ioprio
   can express per-process priority within each cgroup. While this
   makes semantic sense and can be useful in certain scenarios, this
   is also a departure from how people have been using ioprio and it'd
   be involve quite a bit of effort and complexity, likely too much to
   be justified by its inherent usefulness.

Jens, what do you think?

Thanks.

-- 
tejun