From: "Liang, Kan" <kan.liang@intel.com>
To: "peterz@infradead.org" <peterz@infradead.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"acme@kernel.org" <acme@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"namhyung@kernel.org" <namhyung@kernel.org>,
"jolsa@kernel.org" <jolsa@kernel.org>,
"Hunter, Adrian" <adrian.hunter@intel.com>,
"wangnan0@huawei.com" <wangnan0@huawei.com>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"andi@firstfloor.org" <andi@firstfloor.org>
Subject: RE: [PATCH V3 0/6] export perf overheads information (kernel)
Date: Fri, 16 Dec 2016 15:08:33 +0000 [thread overview]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077536804E9@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <1481232434-3574-1-git-send-email-kan.liang@intel.com>
Ping.
Any comments for the series?
Thanks,
Kan
> Subject: [PATCH V3 0/6] export perf overheads information (kernel)
>
> From: Kan Liang <kan.liang@intel.com>
>
> This series only include the kernel related patches.
>
> 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 sampling overhead. However, there
> are other parts which also 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.
> Actually, any passive ways like dynamic interrupt throttle mechanism are
> only palliative. The best way is to export overhead information, provide
> more hints, and help the users design more proper perf command.
>
> For kernel, three parts can bring obvious overhead.
> - sample overhead: For x86, it's the time cost in perf NMI handler.
> - multiplexing overhead: The time cost spends on rotate context.
> - side-band events overhead: The time cost spends on iterating all
> events that need to receive side-band events.
> The time cost of those parts are stored in pmu's per-cpu cpuctx.
> The tool can call PERF_EVENT_IOC_STAT when it's 'done'. Then the kernel
> generates the overhead record PERF_RECORD_OVERHEAD.
>
> User can use the overhead information to refine their perf command and
> get accurate profiling result. For example, if there is high overhead warning,
> user may reduce the number of events/increase the period/decrease the
> frequency.
> Developer can also use the overhead information to find bugs.
>
> Changes since V2:
> - Separate kernel patches from the previous version
> - Add PERF_EVENT_IOC_STAT to control overhead statistics
> - Collect per pmu overhead information
> - Store the overhead information in pmu's cpuctx
> - Add CPU information in overhead record
>
> Changes since V1:
> - fix u32 holes and remove duplicate CPU information
> - configurable overhead logging
> - Introduce the concept of PMU specific overhead and common core
> overhead. Rename NMI overhead to PMU sample overhead
> - Add log_overhead in perf_event_context to indicate the logging of
> overhead
> - Refine the output of overhead information
> - Use perf CPU time to replace perf write data overhead
> - Refine the formula of overhead evaluation
> - Refine perf script
>
> Kan Liang (6):
> perf/core: Introduce PERF_RECORD_OVERHEAD
> perf/core: Add PERF_EVENT_IOC_STAT to control overhead statistics
> perf/x86: implement overhead stat for x86 pmu
> perf/core: calculate multiplexing overhead
> perf/core: calculate side-band events overhead
> perf/x86: calculate sampling overhead
>
> arch/x86/events/core.c | 45 +++++++++++++++++++++++-
> include/linux/perf_event.h | 12 +++++++
> include/uapi/linux/perf_event.h | 44 ++++++++++++++++++++++-
> kernel/events/core.c | 77
> ++++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 175 insertions(+), 3 deletions(-)
>
> --
> 2.4.3
next prev parent reply other threads:[~2016-12-16 15:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 21:27 [PATCH V3 0/6] export perf overheads information (kernel) kan.liang
2016-12-08 21:27 ` [PATCH V3 1/6] perf/core: Introduce PERF_RECORD_OVERHEAD kan.liang
2016-12-08 21:27 ` [PATCH V3 2/6] perf/core: Add PERF_EVENT_IOC_STAT to control overhead statistics kan.liang
2016-12-08 21:27 ` [PATCH V3 3/6] perf/x86: implement overhead stat for x86 pmu kan.liang
2016-12-08 21:27 ` [PATCH V3 4/6] perf/core: calculate multiplexing overhead kan.liang
2016-12-08 21:27 ` [PATCH V3 5/6] perf/core: calculate side-band events overhead kan.liang
2016-12-08 21:27 ` [PATCH V3 6/6] perf/x86: calculate sampling overhead kan.liang
2016-12-16 15:08 ` Liang, Kan [this message]
2017-01-06 15:25 ` [PATCH V3 0/6] export perf overheads information (kernel) Liang, Kan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37D7C6CF3E00A74B8858931C1DB2F077536804E9@SHSMSX103.ccr.corp.intel.com \
--to=kan.liang@intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=wangnan0@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).