Il giorno 06 nov 2017, alle ore 10:22, Ulf Hansson =

[off-list ref] ha scritto:

=20
On 6 November 2017 at 03:21, Jens Axboe [off-list ref] wrote:

quoted

On 11/05/2017 01:39 AM, Paolo Valente wrote:

quoted

=20

quoted

Il giorno 18 ott 2017, alle ore 15:19, Tejun Heo [off-list ref] ha =

scritto:

quoted

quoted

quoted

=20
Hello, Paolo.
=20
On Tue, Oct 17, 2017 at 12:11:01PM +0200, Paolo Valente wrote:
...

quoted

protected by a per-device scheduler lock.  To give you an idea, on =

an

quoted

quoted

quoted

quoted

Intel i7-4850HQ, and with 8 threads doing random I/O in parallel =

on

quoted

quoted

quoted

quoted

null_blk (configured with 0 latency), if the update of groups =

stats is

quoted

quoted

quoted

quoted

removed, then the throughput grows from 260 to 404 KIOPS.  This =

and

quoted

quoted

quoted

quoted

all the other results we might share in this thread can be =

reproduced

quoted

quoted

quoted

quoted

very easily with a (useful) script made by Luca Miccio [1].

=20
I don't think the old request_queue is ever built for multiple CPUs
hitting on a mem-backed device.
=20

=20
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_*

quoted

quoted

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

quoted

quoted

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.
=20
Thus, to deal with such a considerable slowdown, until the overhead =

of

quoted

quoted

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

quoted

quoted

welcome/needed.
=20
We wondered, however, how hazardous it might be to switch the update
of these statistics off.  To answer this question, we investigated =

the

quoted

quoted

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

quoted

quoted

application or service using these statistics (either the variant
updated by bfq, or that updated by cfq).
=20
So, one of the patches we are working on gives the user the
possibility to disable the update of these statistics online.

=20
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:
=20
perf record -g -- whatever test
perf report -g --no-children
=20
and post the top 10 entries from the perf report.
=20
It's pointless to give up on this so soon, when no effort has =

apparently

quoted

been dedicated to figuring out what the actual issue is yet. So no, =

no

quoted

patch that will just disable the stats is going to be accepted.
=20
That said, I have no idea who uses these stats. Surely someone can
answer that question. Tejun?

=20
Jens, Tejun, apologize for side-tracking the discussion.
=20
It sounds to me that these stats should have been put into debugfs,
rather than sysfs from the beginning.
=20

Ulf,
let me just add a bit of info, if useful: four of those stat files are
explicitly meant for debugging (as per the documentation), and created
if CONFIG_DEBUG_BLK_CGROUP=3Dy.

Paolo

Perhaps we could consider moving them to debugfs for the
mq-schedulers, as those are still rather new?
=20
Of course that doesn't solve the high overhead with stat computation,
which seems very reasonable to investigate further, no matter what.
=20
Kind regards
Uffe