> 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. > Maybe my generic description didn't highlight how plain are. If you print, e.g., io_serviced with the current interface, you get -------------------------- 8:0 Read 4291168 8:0 Write 2181577 8:0 Sync 5897755 8:0 Async 574990 8:0 Total 6472745 Total 6472745 -------------------------- With the new, interface, you get *the same output*, if only one policy is attached to this interface file. In, instead - two policies share the the file, because one is active on a device and one on another device - these policies are named, e.g., bfq and pol2 then you get (device number and statistics invented): -------------------------- bfq: 8:0 Read 4291168 8:0 Write 2181577 8:0 Sync 5897755 8:0 Async 574990 8:0 Total 6472745 Total 6472745 pol2: 16:0 Read 238768 16:0 Write 323123 16:0 Sync 43243 16:0 Async 432432 16:0 Total 412435 Total 4341244 -------------------------- So you see the per-device statistics as before, without the problem of inventing a new set of names for every new policy that has the same interface files of an existing policy. Tejun, let's try to converge, to whatever solution you prefer. 4.21 is coming ... and the legacy proportional share interface will be gone with cfq. This will break legacy code using the proportional-share interface on top of bfq. This code may just fail when trying to use interface files that don't exist any longer. Thanks, Paolo > 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 > > -- > You received this message because you are subscribed to the Google Groups "bfq-iosched" group. > To unsubscribe from this group and stop receiving emails from it, send an email to bfq-iosched+unsubscribe@xxxxxxxxxxxxxxxx. > For more options, visit https://groups.google.com/d/optout.
