> Il giorno 06 nov 2017, alle ore 17:22, Jens Axboe <axboe@xxxxxxxxx> ha scritto: > > On 11/06/2017 09:21 AM, Paolo Valente wrote: >> >>> Il giorno 06 nov 2017, alle ore 17:13, Jens Axboe <axboe@xxxxxxxxx> ha scritto: >>> >>> On 11/06/2017 09:11 AM, Paolo Valente wrote: >>>> >>>>> Il giorno 06 nov 2017, alle ore 16:47, Paolo Valente <paolo.valente@xxxxxxxxxx> ha scritto: >>>>> >>>>>> >>>>>> Il giorno 06 nov 2017, alle ore 16:00, Tejun Heo <tj@xxxxxxxxxx> ha scritto: >>>>>> >>>>>> Hello, >>>>>> >>>>>> On Sun, Nov 05, 2017 at 07:21:01PM -0700, Jens Axboe wrote: >>>>>>> It's pointless to give up on this so soon, when no effort has apparently >>>>>>> been dedicated to figuring out what the actual issue is yet. So no, no >>>>>>> patch that will just disable the stats is going to be accepted. >>>>>>> >>>>>>> That said, I have no idea who uses these stats. Surely someone can >>>>>>> answer that question. Tejun? >>>>>> >>>>>> Except for the basic bytes / ios counts, it's all debug fluff, which >>>>>> should have been hidden behind a debug boot param or go under debugfs. >>>>>> I'm not sure we can get rid of them at this point for cfq but I don't >>>>>> see why we'd have them for bfq. >>>>>> >>>>> >>>>> Ok, then I think this is the right time to ask you what I can throw >>>>> way for bfq. According to your documentation, basic non-debug stats >>>>> should be: >>>>> >>>>> blkio.time >>>>> blkio.time_recursive >>>>> blkio.sectors >>>>> blkio.io_service_bytes >>>>> blkio.io_service_bytes_recursive >>>>> blkio.io_serviced >>>>> blkio.io_serviced_recursive >>>>> blkio.io_service_time >>>>> blkio.io_service_time_recursive >>>>> blkio.io_wait_time >>>>> blkio.io_wait_time_recursive >>>>> blkio.io_merged >>>>> blkio.io_merged_recursive >>>>> blkio.io_queued >>>>> blkio.io_queued_recursive >>>>> >>>>> So, I have to keep them in bfq, right? Or is there something I can >>>>> remove for bfq, in your opinion? Of course, I would be very happy to remove stuff! >>>>> >>>> >>>> Or, more mildly, could some of these stats be moved behind >>>> CONFIG_DEBUG_BLK_CGROUP? >>> >>> It'd be nice to have them be runtime enabled, but I don't think >>> that's a hard requirement at all. >> >> So, you mean *all* stats dynamically enabled/disabled, and disabled by >> default. Plus, some of them also statically filtered, that is >> enabled/disabled, through CONFIG_DEBUG_BLK_CGROUP. Is my >> understanding correct? If it is, we will be happy to do it. > > If you go the enable/disable route, don't make them depend on > DEBUG_BLK_CGROUP at all. Just have them be default off, with > some way to switch them on. > Yes. DEBUG_BLK_CGROUP will just serve to keep the for-debugging subset switched off even when the dynamic parameter is on. We'll wait for possible counter-arguments from Tejun, and then start to work on what you propose. Thanks, Paolo > -- > Jens Axboe
