Re: [PATCH 4/8] bfq: Limit number of requests consumed by each cgroup

["Michal Koutný" <mkoutny@suse.com>]

On Wed, Nov 03, 2021 at 02:03:14PM +0100, Jan Kara <jack@suse.cz> wrote:
> Since we stop the loop at bfq_class_idx(entity)

Aha! I overlooked the for loop ends with the entity's class here and not
after the full range of classes.

> I.e., we scale available tags proportionally to bfq_queue weight (which
> scales linearly with IO priority).

Yes, you're working within the "order" of the entity's class and it's
always the last, i.e. least too, so the scale is 1.

> So in principle it can happen that there would be no tag left for a
> process in lower IO priority class - and that is fine, we don't care,
> because we don't want to submit IO from lower IO priority class while
> there is still IO in higher IO priority class.

Actually, can it ever happen that the higher class leaves some tags for
the lower? (IOW, is the CLS_wsum anytime exceeding sum of all active
entities of the CLS at the given point in time?) (1)

> Now consider a situation for a process in BE IO priority class in this
> setting. All processes in BE class can together occupy at most BE_wsum /
> (RT_wsum * IOPRIO_BE_NR + BE_wsum) fraction of tags. This is admittedly
> somewhat arbitrary fraction but it makes sure for each process in RT class
> there are at least as many tags left as for the highest priority process in
> BE class.

Can it happen that bfqq_request_over_limit() is called for a BE entity
before calling it for an RT entity (more precisely, not the
bfqq_request_over_limit() calls but actual allocation of tags)? (2)

> As I wrote above, the highest active IO priority class effectively allows
> processes in this class to consume all tags available for a cgroup. If
> there are lower IO priority classes active as well, we allow them to
> consume some tags but never allow them to consume all of them...

I assume this implies the answer to my previous question (2) is "yes"
and to the question (1) is: "numerically no, but lower class entity can
take some tags if it gets to draw them earlier".

> Yes, this is kind of an extension of bfq_io_prio_to_weight() that allows
> some comparison of queues from different IO priority classes.

I see there's no point using the same values for the weights in the
bfqq_request_over_limit() calculations as bfq_ioprio_to_weight()
calculates given the nature of strict ordering of classes above each
other. Your scoring makes sense to me now.

Reviewed-by: Michal Koutný <mkoutny@suse.com>

(this patch only)