Re: [PATCH V2 00/10] unify the interface of the proportional-share policy in blkio/io

[Paolo Valente]

> Il giorno 18 dic 2018, alle ore 18:22, Paolo Valente <paolo.valente@xxxxxxxxxx> ha scritto:
> 
> 
> 
>> Il giorno 18 dic 2018, alle ore 17:41, Tejun Heo <tj@xxxxxxxxxx> ha scritto:
>> 
>> Hello, Paolo.
>> 
>> On Tue, Dec 18, 2018 at 08:48:10AM +0100, Paolo Valente wrote:
>>> If Tejun cannot see any solution to his concern, then can we just
>>> switch to this extension, considering that
>>> - for non-shared names the interface is *identical* to the current
>>> one;
>>> - by using this new interface, and getting feedback we could
>>> understand how to better handle Tejun's concern?
>>> A lot of systems do use weights, and people don't even know that these
>>> systems don't work correctly in blk-mq.  And they won't work correctly
>>> in any available configuration from 4.21, if we don't fix this problem.
>> 
>> So, when seen from userland, how it should behave isn't vague or
>> complicated.  For a given device and policy type, there can be only
>> one implementation active.
> 
> Yes, but the problem is the opposite. You may have
> - two different policies, with the same interface parameter, 
> - one active on one device
> - the other one active on another device
> 
> In that case, statistics from one policy necessarily differ from
> statistics from the other policy.
> 
> In this respect, in a system with more than one drive it already
> happens that the same policy is active on different devices.  When
> printing a statistics interface file for the policy, the output will
> be a list of separate statistics, with a bunch of statistics *for
> each* drive (plus a grand total in some cases).
> 
> So, our proposal simply extends this scheme in the most natural way:
> if, now, also two or more policies share the same statistics file,
> then the output will be a list of separate statistics, one for each
> policy.  The statistics for each policy will be tagged with the policy
> name, and will have the same identical form as above.  It seems the
> most natural hierarchical extension of the same scheme.
> 
> At any rate, if you don't like it, just tell us how you prefer it
> done.  Do you prefer the sharing of statistics file to be simply
> forbidden?  (If this can be done.) I think such an incomplete solution
> would preserve part of the current mess; but, if this allows us to
> exit from this impasse, then it is ok for me.
> 
> *Any* feasible option is ok for me. Just pick one.
> 
>> It doesn't make sense to have two weight
>> mechanisms active on one device, right?
> 
> (Un)fortunately, the problem are not weights.  There won't be two
> weights for two policies expiring a weight parameter.  The problems

s/expiring/sharing sorry