All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Liang, Kan" <kan.liang@intel.com>
Cc: "mingo@redhat.com" <mingo@redhat.com>,
	"acme@kernel.org" <acme@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"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 V2 03/13] perf/x86: output sampling overhead
Date: Tue, 6 Dec 2016 19:26:47 +0100	[thread overview]
Message-ID: <20161206182647.GC3107@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F07750CA9EFB@SHSMSX103.ccr.corp.intel.com>

On Tue, Dec 06, 2016 at 03:47:40PM +0000, Liang, Kan wrote:

> > It doesn't record anything, it generates the output. And it doesn't explain
> > why that needs to be in pmu::del(), in general that's a horrible thing to do.
> 
> Yes, it only generate/log the output. Sorry for the confused wording.
> 
> The NMI overhead is pmu specific overhead. So the NMI overhead output
> should be generated in pmu code.

True, but you're also accounting in a per-cpu bucket, which means it
includes all events. At which point the per-event overhead thing doesn't
really make sense.

It also means that previous sessions influence the numbers of our
current session; there's no explicit reset of the numbers.

> I assume that the pmu:del is the last called pmu function when perf finish.
> Is it a good place for logging?

No, its horrible. Sure, we'll call pmu::del on events, but yuck.

You really only want _one_ invocation when you stop using the event, and
we don't really have a good place for that. But instead of creating one,
you do horrible things.

Now, I realize there's a bit of a catch-22 in that the moment we know
the event is going away, its already gone from userspace. So we cannot
dump data from there in general..

Howver, if we have output redirection we can, but that would make things
depend on that and it cannot be used for the last event who's buffer
we're using.

Another option would be to introduce PERF_EVENT_IOC_STAT or something
like that, and have the tool call that when its 'done'.

  reply	other threads:[~2016-12-06 18:27 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02 21:19 [PATCH V2 00/13] export perf overheads information kan.liang
2016-12-02 21:19 ` [PATCH V2 01/13] perf/core: Introduce PERF_RECORD_OVERHEAD kan.liang
2016-12-06 11:26   ` Peter Zijlstra
2016-12-02 21:19 ` [PATCH V2 02/13] perf/core: output overhead when sched out from context kan.liang
2016-12-06 11:21   ` Peter Zijlstra
2016-12-02 21:19 ` [PATCH V2 03/13] perf/x86: output sampling overhead kan.liang
2016-12-06 11:20   ` Peter Zijlstra
2016-12-06 15:02     ` Liang, Kan
2016-12-06 15:32       ` Peter Zijlstra
2016-12-06 15:47         ` Liang, Kan
2016-12-06 18:26           ` Peter Zijlstra [this message]
2016-12-07 19:03             ` Liang, Kan
2016-12-06 11:38   ` Peter Zijlstra
2016-12-02 21:19 ` [PATCH V2 04/13] perf/core: output multiplexing overhead kan.liang
2016-12-06 11:23   ` Peter Zijlstra
2016-12-06 15:04     ` Liang, Kan
2016-12-02 21:19 ` [PATCH V2 05/13] perf/core: output side-band events overhead kan.liang
2016-12-06 11:25   ` Peter Zijlstra
2016-12-02 21:19 ` [PATCH V2 06/13] perf tools: option to disable overhead collection kan.liang
2016-12-02 21:19 ` [PATCH V2 07/13] perf tools: handle PERF_RECORD_OVERHEAD record type kan.liang
2016-12-06 11:16   ` Jiri Olsa
2016-12-02 21:19 ` [PATCH V2 08/13] perf tools: show kernel overhead kan.liang
2016-12-06 11:16   ` Jiri Olsa
2016-12-06 11:16   ` Jiri Olsa
2016-12-06 11:16   ` Jiri Olsa
2016-12-02 21:19 ` [PATCH V2 09/13] perf script: " kan.liang
2016-12-04 21:25   ` Jiri Olsa
2016-12-05 14:47     ` Liang, Kan
2016-12-02 21:19 ` [PATCH V2 10/13] perf tools: add time related functions kan.liang
2016-12-06 11:16   ` Jiri Olsa
2016-12-02 21:19 ` [PATCH V2 11/13] perf tools: introduce PERF_RECORD_USER_OVERHEAD kan.liang
2016-12-02 21:19 ` [PATCH V2 12/13] perf tools: record user space profiling cost kan.liang
2016-12-02 21:19 ` [PATCH V2 13/13] perf report: warn on high overhead kan.liang

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=20161206182647.GC3107@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.