Re: [PATCH -tip, final] perf, x86: Add hw_watchdog_set_attr() in asake of nmi-watchdog on P4

[Cyrill Gorcunov]

On Tue, Jul 05, 2011 at 03:10:05PM +0200, Ingo Molnar wrote:
> 
> * Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote:
> 
> > perf, x86: P4 PMU - Add hw_watchdog_set_attr helper to simulate cpu-cycles counting in nmi-watchdog
> > 
> > Because of constraints existed in Netburst PMU counting
> > cpu cycles is allowed for one consumer only.
> > 
> > If the kernel is booted up with nmi-watchdog enabled
> > the watchdog become a consumer of such event and there
> > is no more room left for "perf top" and friends (ie any
> > attempts to count cpu cycles simultaneously with nmi-watchdog
> > doomed to fail).
> 
> Hm, what is the symptom - 'perf top' reports nothing?

Exactly, last time I had access to p4 machine (about 2 month
ago I think) with nmi-watchdog enabled perf top simply rendered
empty screen with standart header on top.

> 
> If multiple users request cycles then perf will time-share them - 
> this is what happens if you run many 'perf top' or 'perf stat' 
> sessions in parallel for example. For example i just tried to run six 
> separate 'perf top' in parallel - and all six worked fine.
> 
> So the question is, why does the NMI watchdog prevent 'perf top' from 
> working on a P4?
>

Because core and nehalem can use two cpu-cycles counters simultaneously
counting same event, and when nmi-watchdog is enabled on such pmus the one
counter assigned to nmi-watchdog, a second counter assigned to perf top and friends.
And nmi-watchdog event is "never released" event as far as I remember,
it runs all the time while system works.

In P4 every event has a restriction on which counter it can run and which
assitional registers it can use. So once nmi-watchdog has borrowed an event
(and associated resurses) noone else can access to these resources forever,
and hence perf top fails since it tries to gain access to same event.

	Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/