[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20070612123219.GE32163@frankl.hpl.hp.com>
Date: Tue, 12 Jun 2007 05:32:19 -0700
From: Stephane Eranian <eranian@....hp.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
Stephane Eranian <eranian@....hp.com>, levon@...ementarian.org
Subject: problem with NMI MSR reserve routines
Andi,
I am running into several issues related to the newly restructured
NMI MSR allocator in perfctr-watchdog.c. There are issues with Oprofile
and also with perfmon.
Let me describe the Oprofile issue first (because perfmon is similar).
The fill_in_addresses() callback for Oprofile systematically invokes the
reserve_perfctr_nmi()/reserve_evntsel_nmi() routines regardless
of whether NMI watchdog is active or not. It uses those routines as
a generic PMU register allocator which it is not in its current form.
The issue is that the reserve_*() have a side effect when wd_ops is not
yet defined. The nmi_*_msr_to_bit() routines return 0 which means you've
collapsed all MSR to a single bit. The first reserve() will return success
the others will return failure, thus the caller will assume only one PMU
register is present. This what you can see in the following trace for
Oprofile on Opteron with nmi_watchdog=0:
tired kernel: res_ctr @0xc0010004 returns 1 (success)
tired kernel: res_ctr @0xc0010005 returns 0 (failure)
tired kernel: res_ctr @0xc0010006 returns 0
tired kernel: res_ctr @0xc0010007 returns 0
tired kernel: res_sel @0xc0010000 returns 1 (success)
tired kernel: res_sel @0xc0010001 returns 0 (failure)
tired kernel: res_sel @0xc0010002 returns 0
tired kernel: res_sel @0xc0010003 returns 0
I think we either need to fix up fill_in_addresses X86 routines to check
for nmi_watchdog() or (better) change the allocator to work differently,be
independent of NMI watchdog.
--
-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists