Thread (19 messages) 19 messages, 2 authors, 2021-09-15

Re: [PATCH v2 4/4] block, bfq: consider request size in bfq_asymmetric_scenario()

From: Paolo Valente <hidden>
Date: 2021-09-15 07:37:09
Also in: lkml

Il giorno 7 set 2021, alle ore 13:29, yukuai (C) [off-list ref] ha scritto:

On 2021/08/27 1:00, Paolo Valente wrote:
quoted
quoted
Il giorno 6 ago 2021, alle ore 04:08, Yu Kuai [off-list ref] ha scritto:

There is a special case when bfq do not need to idle when more than
one groups is active:
Unfortunately, there is a misunderstanding here.  If more than one
group is active, then idling is not needed only if a lot of symmetry
conditions also hold:
- all active groups have the same weight
- all active groups contain the same number of active queues
Hi, Paolo

I didn't think of this contition.

It's seems that if we want to idle when more than one group is active,
there are two additional conditions:

- all dispatched requests have the same size
- all active groups contain the same number of active queues
Also the weights and the I/O priorities of the queues inside the
groups needs to be controlled, unfortunately.
Thus we still need to track how many queues are active in each group.
The conditions seems to be too much, do you think is it worth it to
add support to idle when more than one group is active?
I think I see your point.  The problem is that these states are
dynamic.  So, if we suspend tracking all the above information while
more than one group is active, then we are with no state in case only
one group remains active.

Thanks,
Paolo
Thanks
Kuai
quoted
- all active queues have the same weight
- all active queues belong to the same I/O-priority class
- all dispatched requests have the same size
Similarly, if only one group is active, then idling is not needed only
if the above last three conditions hold.
The current logic, including your changes up to your previous patch,
is simply ignoring the last condition above.
So, unfortunately, your extra information about varied request size
should be used in the opposite way than how you propose to use it.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help