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

On 8/12/21 11:51 AM, Tejun Heo wrote:

On Wed, Aug 11, 2021 at 01:22:20PM -0700, Bart Van Assche wrote:

quoted

On 8/11/21 12:14 PM, Tejun Heo wrote:

quoted

On Wed, Aug 11, 2021 at 11:49:10AM -0700, Bart Van Assche wrote:

quoted

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?

On the surface, #2 makes the most sense. But you'd then have to apply
some scaling before it reaches the hardware side or is factored in by
the underlying scheduler, or you could have a high priority from a
cgroup that has small share of the total resources, yet ends up being
regarded as more important than a lower priority request from a cgroup
that has a much higher share of the total resources.

Hence not really sure it makes a lot of sense... We could probably come
up with some heuristics that make some sense, but they'd still just be
heuristics.

-- 
Jens Axboe