From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Robert Richter <rric@kernel.org>, Vince Weaver <vince@deater.net>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] perf/stat: Add --disable-hwdt
Date: Mon, 6 Feb 2017 13:22:31 +0100 [thread overview]
Message-ID: <20170206122231.GA9404@gmail.com> (raw)
In-Reply-To: <20170206121506.mtknwusus4djp2sx@pd.tnic>
* Borislav Petkov <bp@alien8.de> wrote:
> Hi guys,
>
> so I've been tracing recently on an AMD F15h which has those funky counter
> constraints and am seeing this:
>
> # ./perf stat sleep 1
>
> Performance counter stats for 'sleep 1':
>
> 0.749208 task-clock (msec) # 0.001 CPUs utilized
> 1 context-switches # 0.001 M/sec
> 0 cpu-migrations # 0.000 K/sec
> 54 page-faults # 0.072 M/sec
> 1,122,815 cycles # 1.499 GHz
> 286,740 stalled-cycles-frontend # 25.54% frontend cycles idle
> <not counted> stalled-cycles-backend (0.00%)
> ^^^^^^^^^^^^
> <not counted> instructions (0.00%)
> ^^^^^^^^^^^^
> <not counted> branches (0.00%)
> <not counted> branch-misses (0.00%)
>
> 1.001550070 seconds time elapsed
>
>
> The problem is that the HW watchdog thing is already taking up a
> counter so when perf stat uses the default counters and when we reach
> stalled-cycles-backend, we run out of counters for the remaining events.
>
> So how about something like this:
>
> # ./perf stat --disable-hwdt sleep 1
>
> Performance counter stats for 'sleep 1':
>
> 0.782552 task-clock (msec) # 0.001 CPUs utilized
> 1 context-switches # 0.001 M/sec
> 0 cpu-migrations # 0.000 K/sec
> 55 page-faults # 0.070 M/sec
> 1,163,246 cycles # 1.486 GHz
> 293,598 stalled-cycles-frontend # 25.24% frontend cycles idle
> 400,017 stalled-cycles-backend # 34.39% backend cycles idle
> 676,505 instructions # 0.58 insn per cycle
> # 0.59 stalled cycles per insn
> 133,822 branches # 171.007 M/sec
> 7,319 branch-misses # 5.47% of all branches
>
> 1.001660058 seconds time elapsed
>
> We did explore other opportunities on IRC like sharing counters or
> making the HW WDT thing a 'soft' counter but all those are nasty and
> probably not really worth the trouble of touching perf core just so that
> this works.
>
> Besides, future generations don't have those constraints anymore so it
> is only F15h.
>
> Below is a silly patch as a syntactic sugar helper for perf stat. This
> is just an RFC anyway, I'll do it properly with fopen() if you're ok
> with the approach.
Looks sensible, and I'd in fact make this the new default behavior (if root runs
perf stat) - i.e. add a flag to re-enable it, for the rare case where we want to
debug a hard deadlock while running perf stat ...
Thanks,
Ingo
next prev parent reply other threads:[~2017-02-06 12:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-06 12:15 [RFC PATCH] perf/stat: Add --disable-hwdt Borislav Petkov
2017-02-06 12:22 ` Ingo Molnar [this message]
2017-02-06 12:41 ` Borislav Petkov
2017-02-06 12:44 ` Ingo Molnar
2017-02-06 12:49 ` Borislav Petkov
2017-02-06 13:18 ` Robert Richter
2017-02-06 13:23 ` Borislav Petkov
2017-02-07 7:25 ` Ingo Molnar
2017-02-07 10:54 ` Borislav Petkov
2017-02-07 15:06 ` Borislav Petkov
2017-02-11 17:03 ` Borislav Petkov
2017-02-11 17:59 ` Ingo Molnar
2017-02-11 18:32 ` Borislav Petkov
2017-02-11 20:41 ` Ingo Molnar
2017-03-07 7:21 ` [tip:perf/core] perf stat: Issue a HW watchdog disable hint tip-bot for Borislav Petkov
2017-02-06 14:23 ` [RFC PATCH] perf/stat: Add --disable-hwdt Vince Weaver
2017-02-06 17:02 ` Borislav Petkov
2017-02-07 1:08 ` Borislav Petkov
2017-02-07 1:09 ` [PATCH 1/2] tools/lib/api/fs: Add procfs int read/write helpers Borislav Petkov
2017-02-07 1:43 ` Arnaldo Carvalho de Melo
2017-02-07 10:30 ` Borislav Petkov
2017-02-07 15:00 ` Arnaldo Carvalho de Melo
2017-02-07 15:08 ` Borislav Petkov
2017-02-07 15:34 ` Arnaldo Carvalho de Melo
2017-02-07 1:10 ` [PATCH 2/2] perf stat: Disable HW watchdog around a perf stat session Borislav Petkov
2017-02-07 1:45 ` Arnaldo Carvalho de Melo
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=20170206122231.GA9404@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rric@kernel.org \
--cc=vince@deater.net \
/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.