From: Stephane Eranian <eranian@hpl.hp.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
Stephane Eranian <eranian@hpl.hp.com>,
levon@movementarian.org
Subject: problem with NMI MSR reserve routines
Date: Tue, 12 Jun 2007 05:32:19 -0700 [thread overview]
Message-ID: <20070612123219.GE32163@frankl.hpl.hp.com> (raw)
In-Reply-To: <20070601105753.GE7217@one.firstfloor.org>
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
prev parent reply other threads:[~2007-06-12 12:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 13:48 [PATCH 13/22] 2.6.22-rc3 perfmon2 : common core functions Stephane Eranian
2007-05-31 15:01 ` Andi Kleen
2007-05-31 17:16 ` Stephane Eranian
2007-05-31 17:28 ` Andi Kleen
2007-05-31 18:29 ` Christoph Hellwig
2007-05-31 18:43 ` Andi Kleen
2007-05-31 18:53 ` Christoph Hellwig
2007-05-31 19:02 ` Andi Kleen
2007-05-31 20:44 ` Stephane Eranian
2007-06-04 11:56 ` Stephane Eranian
[not found] ` <20070601101648.GD24898@frankl.hpl.hp.com>
[not found] ` <20070601105753.GE7217@one.firstfloor.org>
2007-06-12 12:32 ` Stephane Eranian [this message]
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=20070612123219.GE32163@frankl.hpl.hp.com \
--to=eranian@hpl.hp.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=levon@movementarian.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®