* Borislav Petkov wrote:
> On Sat, Feb 11, 2017 at 06:59:10PM +0100, Ingo Molnar wrote:
> > So I checked the perf-list manpage and it didn't tell me much about how to
> > disable
> > the NMI watchdog.
>
> Oh, it is buried there:
>
> "
> EVENT GROUPS
>
>
> ...
>
>
> Globally p
On Sat, Feb 11, 2017 at 06:59:10PM +0100, Ingo Molnar wrote:
> So I checked the perf-list manpage and it didn't tell me much about how to
> disable
> the NMI watchdog.
Oh, it is buried there:
"
EVENT GROUPS
...
Globally pinned events can limit the number of counters available fo
* Borislav Petkov wrote:
> Ok,
>
> turns out perf-list(1) already talks about it in the "EVENT GROUPS"
> section. How about this then:
>
> ---
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index a02f2e965628..2d18283574db 100644
> --- a/tools/perf/builtin-stat.c
> +++
Ok,
turns out perf-list(1) already talks about it in the "EVENT GROUPS"
section. How about this then:
---
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index a02f2e965628..2d18283574db 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -146,6 +146,7 @@
Btw,
I'm wondering if, alternatively, we add this to the manpage of perf stat
and be done with it:
"Remember to turn off HW watchdog temporarily as it is taking up one hw
counter:
$ echo 0 > /proc/sys/kernel/nmi_watchdog
... perf workload
$ echo 1 > /proc/sys/kernel/nmi_watchdog
in case some
On Tue, Feb 07, 2017 at 08:25:12AM +0100, Ingo Molnar wrote:
> But there's only so much we can do about that, the /proc/sys API is
> fundamentally
> lossy in that regard. We'd have to add much more involved kernel support to
> guarantee that the watchdog state is restored.
So I think doing all
* Borislav Petkov wrote:
> On Mon, Feb 06, 2017 at 02:18:32PM +0100, Robert Richter wrote:
>
> > Isn't there the danger the previous watchdog state is never restored if for
> > some reason perf got killed? So maybe have some other task running that
> > restores it once perf is gone.
>
> Curre
Ok,
here's something (as replies to this message) which looks much more
decent.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Feb 06, 2017 at 09:23:33AM -0500, Vince Weaver wrote:
> minor issue, but is it possibly to do anything about dmesg spam? From
> what I recall every time you enable and disable the watchdog the kernel
> prints a message. Makes for messy logs, especially when you run the
> perf_fuzzer as
On Mon, 6 Feb 2017, Robert Richter wrote:
> On 06.02.17 13:49:37, Borislav Petkov wrote:
> > On Mon, Feb 06, 2017 at 01:44:48PM +0100, Ingo Molnar wrote:
> > > Yeah, if for some whatever reason perf locks up while running perf stat
> > > as root,
> > > so I'd keep the option, as a general princi
On Mon, Feb 06, 2017 at 02:18:32PM +0100, Robert Richter wrote:
> Isn't there the danger the previous watchdog state is never restored
> if for some reason perf got killed? So maybe have some other task
> running that restores it once perf is gone.
Currently, I'm restoring it in the atexit() sigha
On 06.02.17 13:49:37, Borislav Petkov wrote:
> On Mon, Feb 06, 2017 at 01:44:48PM +0100, Ingo Molnar wrote:
> > Yeah, if for some whatever reason perf locks up while running perf stat as
> > root,
> > so I'd keep the option, as a general principle. :-/
>
> --dont-disable-hwdt it is.
Isn't there
On Mon, Feb 06, 2017 at 01:44:48PM +0100, Ingo Molnar wrote:
> Yeah, if for some whatever reason perf locks up while running perf stat as
> root,
> so I'd keep the option, as a general principle. :-/
--dont-disable-hwdt it is.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid
* Borislav Petkov wrote:
> On Mon, Feb 06, 2017 at 01:22:31PM +0100, Ingo Molnar wrote:
> > 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
On Mon, Feb 06, 2017 at 01:22:31PM +0100, Ingo Molnar wrote:
> 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 ...
I'd probabl
* Borislav Petkov 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 u
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 conte
17 matches
Mail list logo
