> 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 concerns statistics. See above. > So, the interface should only > present what makes sense to the user for both configuration knobs and > statistics, and that'd be a hard requirement because we don't want to > present confusing spurious information to userspace. > > There seemd to have been significant misunderstandings as to what the > requirements are when this was discussed way back, so idk what the > good path forward is at this point. Just keep the current names? > I don't clearly understand how "just picking the current names" is a way forward, but if we do not make this extension, in a way or the other, then two policies will simply not be allowed to share the same interface files. And we will be still at the starting point. Thanks, Paolo > Thanks. > > -- > tejun
