> Il giorno 20 nov 2018, alle ore 17:50, Paolo Valente <paolo.valente@xxxxxxxxxx> ha scritto: > > > >> Il giorno 20 nov 2018, alle ore 17:28, Tejun Heo <tj@xxxxxxxxxx> ha scritto: >> >> Hello, Paolo. >> >> On Mon, Nov 19, 2018 at 11:34:14AM +0100, Paolo Valente wrote: >>> - if all entities produce the same output, the this common output is >>> shown only once; >>> - if the outputs differ, then every per-entity output is shown, >>> followed by the name of the entity that produced that output. >> >> So, this doesn't make sense to me. One set of numbers is meaningful, >> the other not and the user doesn't have a way to tell which one is. >> It makes no sense to present both numbers. >> > > I do agree that these numbers may confuse. Before discussing how to > do this better, let me tell you why we are showing them. > > In the first place, the need for a diversified output showed up in the > following case. Given a group using the blkio/io controller, and two > drives > - one with legacy block and cfq > - one with blk-mq and bfq > there will be different statistics for each scheduler, for the same > interface files. > > Then we understood that exactly the same happens with throttling, in > case the latter is activated on different devices w.r.t. bfq. > > In addition, the same may happen, in the near future, with the > bandwidth controller Josef is working on. If the controller can be > configured per device, as with throttling, then statistics may differ, > for the same interface files, between bfq, throttling and that > controller. > > More general examples could be made considering that this extension is > for the generic cgroup interface. > > Of course, suggestions for a clearer way to show these numbers are > more than welcome! Maybe involved device identifiers can be somehow > gathered by the entities providing these numbers, and then shown? In > this respect, consider that, even without this extension, one still > has the fundamental problem of not knowing to which devices numbers > apply (unless I'm missing something else). > Hi Tejun, have you had time to look into this? Any improvement to this interface is ok for us. We are only interested in finally solving this interface issue, as, for what concerns us directly, it has been preventing legacy code to use bfq for years. Thanks, Paolo > 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.
