[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161124042702.GA10321@gmail.com>
Date: Thu, 24 Nov 2016 05:27:02 +0100
From: Ingo Molnar <mingo@...nel.org>
To: kan.liang@...el.com
Cc: peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
linux-kernel@...r.kernel.org, alexander.shishkin@...ux.intel.com,
tglx@...utronix.de, namhyung@...nel.org, jolsa@...nel.org,
adrian.hunter@...el.com, wangnan0@...wei.com, mark.rutland@....com,
andi@...stfloor.org
Subject: Re: [PATCH 00/14] export perf overheads information
* kan.liang@...el.com <kan.liang@...el.com> wrote:
> From: Kan Liang <kan.liang@...el.com>
>
> Profiling brings additional overhead. High overhead may impacts the
> behavior of the profiling object, impacts the accuracy of the
> profiling result, and even hang the system.
> Currently, perf has dynamic interrupt throttle mechanism to lower the
> sample rate and overhead. But it has limitations.
> - The mechanism only focus in the overhead from NMI. However, there
> are other parts which bring big overhead. E.g, multiplexing.
> - The hint from the mechanism doesn't work on fixed period.
> - The system changes which caused by the mechanism are not recorded
> in the perf.data. Users have no idea about the overhead and its
> impact.
> Acctually, any passive ways like dynamic interrupt throttle mechanism
> are only palliative. The best way is to export overheads information,
> provide more hints, and help the users design more proper perf command.
>
> According to our test, there are four parts which can bring big overhead.
> They include NMI handler, multiplexing handler, iterate side-band events,
> and write data in file. Two new perf record type PERF_RECORD_OVERHEAD and
> PERF_RECORD_USER_OVERHEAD are introduced to record the overhead
> information in kernel and user space respectively.
> The overhead information is the system per-CPU overhead, not per-event
> overhead. The implementation takes advantage of the existing event log
> mechanism.
> To reduce the additional overhead from logging overhead information, the
> overhead information only be output when the event is going to be
> disabled or task is scheduling out.
>
> In perf report, the overhead will be checked automatically. If the
> overhead rate is larger than 10%. A warning will be displayed.
> A new option is also introduced to display detial per-CPU overhead
> information.
>
> Current implementation only include four overhead sources. There could be
> more in other parts. The new overhead source can be easily added as a
> new type.
Please include sample output of the new instrumentation!
Not even the tooling patches show any of the output, nor is it clear anywhere what
kind of 'overhead' measurement it is, what the units are, what the metrics are,
how users can _use_ this information, etc.
This is totally inadequate description.
Thanks,
Ingo
Powered by blists - more mailing lists