On Wed, Nov 03, 2021 at 02:03:14PM +0100, Jan Kara <jack@xxxxxxx> 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@xxxxxxxx> (this patch only)
