On 6 November 2017 at 03:21, Jens Axboe <axboe@xxxxxxxxx> wrote: > On 11/05/2017 01:39 AM, Paolo Valente wrote: >> >>> Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo <tj@xxxxxxxxxx> ha scritto: >>> >>> Hello, Paolo. >>> >>> On Tue, Oct 17, 2017 at 12:11:01PM +0200, Paolo Valente wrote: >>> ... >>>> protected by a per-device scheduler lock. To give you an idea, on an >>>> Intel i7-4850HQ, and with 8 threads doing random I/O in parallel on >>>> null_blk (configured with 0 latency), if the update of groups stats is >>>> removed, then the throughput grows from 260 to 404 KIOPS. This and >>>> all the other results we might share in this thread can be reproduced >>>> very easily with a (useful) script made by Luca Miccio [1]. >>> >>> I don't think the old request_queue is ever built for multiple CPUs >>> hitting on a mem-backed device. >>> >> >> Hi, >> from our measurements, the code and the comments received so far in >> this thread, I guess that reducing the execution time of blkg_*stats_* >> functions is not an easy task, and is unlikely to be accomplished in >> the short term. In this respect, we have unfortunately found out that >> executing these functions causes a very high reduction of the >> sustainable throughput on some CPUs. For example, -70% on an ARM >> CortexTM-A53 Octa-core. >> >> Thus, to deal with such a considerable slowdown, until the overhead of >> these functions gets reduced, it may make more sense to switch the >> update of these statistics off, in all cases where these statistics >> are not used, while higher performance (or lower power consumption) is >> welcome/needed. >> >> We wondered, however, how hazardous it might be to switch the update >> of these statistics off. To answer this question, we investigated the >> extent at which these statistics are used by applications and >> services. Mainly, we tried to survey relevant people or >> forums/mailing lists for involved communities: Linux distributions, >> systemd, containers and other minor communities. Nobody reported any >> application or service using these statistics (either the variant >> updated by bfq, or that updated by cfq). >> >> So, one of the patches we are working on gives the user the >> possibility to disable the update of these statistics online. > > If you want help with this, provide an easy way to reproduce this, > and/or some decent profiling output. There was one flamegraph posted, > but that was basically useless. Just do: > > perf record -g -- whatever test > perf report -g --no-children > > and post the top 10 entries from the perf report. > > 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? Jens, Tejun, apologize for side-tracking the discussion. It sounds to me that these stats should have been put into debugfs, rather than sysfs from the beginning. Perhaps we could consider moving them to debugfs for the mq-schedulers, as those are still rather new? Of course that doesn't solve the high overhead with stat computation, which seems very reasonable to investigate further, no matter what. Kind regards Uffe
