> Il giorno 06 nov 2017, alle ore 17:03, Jens Axboe <axboe@xxxxxxxxx> ha scritto: > > On 11/06/2017 08:00 AM, Tejun Heo wrote: >> 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. > > If that's the case, how about having some way to then turn it on and > leave it off by default? The metrics could still be useful, and > there's value in having them the same. But if the overhead is high > AND there's no use case for it outside of debugging, it should not > be on by default for neither cfq nor bfq. > Yes, these were exactly my motivations and plan for bfq! However, at this point, I think that Tejun's answer to my detailed question about what to keep and what not to keep may greatly help in two respects. First, to clarify the actual use of these files, second to understand the actual impact on performance. In fact, as I wrote in some of my previous emails in this thread, some functions are much heavier than others. Those to update debug stats seems to be the heaviest, and, fortunately, would be already behind the CONFIG_DEBUG_BLK_CGROUP option. Thanks, Paolo > -- > Jens Axboe >
