On 11/06/2017 09:37 AM, Tejun Heo wrote: > On Mon, Nov 06, 2017 at 05:33:45PM +0100, Paolo Valente wrote: >> >>> Il giorno 06 nov 2017, alle ore 17:30, Tejun Heo <tj@xxxxxxxxxx> ha scritto: >>> >>> Hello, >>> >>> On Mon, Nov 06, 2017 at 05:26:38PM +0100, Paolo Valente wrote: >>>> 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. >>> >>> So, I think the only *really* required ones are io_serviced and the >>> corresponding byte counts, which are tracked by blk-cgroup core >>> anyway. Everything else can be hidden behind an obviously debug boot >>> param, say, bfq.__DEBUG__extra_stats or whatever. >>> >> >> ok, can we change it, or do you want us to change it, for cfq too? > > I don't have a strong opinion there but it coudl be more hassle than > its worth given how long the stats have been out there. idk. > > Please also note that you can still allow the extra stats to be > enabled run-time through /sys/kernel/module moduleparams and gate them > with the static_branch. No idea whether making it that way is > worthwhile tho. Creating / removing the files dynamically is > supported but given that some stats need to be tracking all the time > to be correct (like # in flights), it seems kinda silly. Yeah, I'd keep them enable-only through some boot/module parameter. Folks using this can just reboot to turn them back off. Bonus points for doing the same for CFQ. -- Jens Axboe
