From: "Björn Steinbrink" <B.Steinbrink@gmx.de>
To: Stephane Eranian <eranian@hpl.hp.com>
Cc: Andi Kleen <ak@suse.de>,
mingo@elte.hu, linux-kernel@vger.kernel.org,
levon@movementarian.org, perfmon@napali.hpl.hp.com,
oprofile-list@lists.sourceforge.net, wcohen@redhat.com,
akpm@linux-foundation.org
Subject: Re: [perfmon] Re: [PATCH 1/2] Separate the performance counter allocation from the LAPIC NMI watchdog
Date: Fri, 22 Jun 2007 09:13:54 +0200 [thread overview]
Message-ID: <20070622071354.GA20506@atjola.homenet> (raw)
In-Reply-To: <20070621083645.GA26740@frankl.hpl.hp.com>
Hi Stephane,
On 2007.06.21 01:36:45 -0700, Stephane Eranian wrote:
> Bjorn,
>
>
> On Wed, Jun 20, 2007 at 02:59:33PM -0700, Stephane Eranian wrote:
> > Bjorn,
> >
> > I ran into one issue related with the new allocator.
Should be the same with 2.6.21 and earlier, the "new" allocator should
do exactly the samething, it just fixes the breakage introduced in the
post-2.6.21 cleanup.
> > In the case of a Core 2 Duo processor, the PMU implements more
> > than just basic counters. In particular it supports fixed counters
> > and PEBS where both use another set of MSRs. Those are not within
> > a 66 bit distance from MSR_ARCH_PERFMON_EVNTSEL0. Thus the allocator
> > fails with an assertion.
How far away are they?
> >
> > I do know that perfmon is the only consumer of those extended
> > features TODAY. Yet I think we need to define the allocator such
> > that it can work with other "distant" MSRs as well.
> >
>
> I think that a workaround for this issue could be for the allocator
> to grant the requests for registers outside of the range, i.e., register
> that it does not see/manage.
That would also allow multiple subsystems to use them at the same time.
And whoever adds the second user of those MSRs might not be aware of the
just-grant-it policy of the allocator. And bugs that arise due to such
problems will probably become a real PITA to track down.
Unfortunately, I don't see any elegant solution to this atm, and of
course making your code simply circumvent the allocator isn't an option
either.
Thanks,
Björn
next prev parent reply other threads:[~2007-06-22 7:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-12 15:02 OProfile issues Stephane Eranian
2007-06-12 18:37 ` Chris Wright
2007-06-12 18:38 ` Chuck Ebbert
2007-06-12 19:07 ` Björn Steinbrink
2007-06-13 1:41 ` [PATCH] Separate performance counter reservation from nmi watchdog Björn Steinbrink
2007-06-13 16:46 ` Björn Steinbrink
2007-06-18 9:52 ` Stephane Eranian
2007-06-18 10:32 ` Björn Steinbrink
[not found] ` <11823357571842-git-send-email->
2007-06-20 10:35 ` [PATCH 1/2] Separate the performance counter allocation from the LAPIC NMI watchdog Björn Steinbrink
2007-06-20 10:35 ` [PATCH 2/2] Finish separation of the performance counter allocator from the " Björn Steinbrink
2007-06-20 12:31 ` [PATCH 1/2] Separate the performance counter allocation from the LAPIC " Andi Kleen
2007-06-20 12:49 ` [perfmon] " Stephane Eranian
2007-06-20 13:01 ` Andi Kleen
2007-06-20 18:33 ` Björn Steinbrink
2007-06-20 18:34 ` [PATCH 1/2] Always probe the " Björn Steinbrink
2007-06-25 19:09 ` Andrew Morton
2007-06-25 19:36 ` Andi Kleen
2007-06-25 20:01 ` Stephane Eranian
2007-06-25 20:36 ` Andi Kleen
2007-06-25 21:04 ` Björn Steinbrink
2007-06-25 21:06 ` Björn Steinbrink
2007-06-20 18:35 ` [PATCH 2/2] Reserve the right performance counter for the Intel PerfMon " Björn Steinbrink
2007-06-20 21:59 ` [perfmon] Re: [PATCH 1/2] Separate the performance counter allocation from the LAPIC " Stephane Eranian
2007-06-21 8:36 ` Stephane Eranian
2007-06-22 7:13 ` Björn Steinbrink [this message]
2007-06-22 10:02 ` Stephane Eranian
2007-06-20 13:18 ` Björn Steinbrink
2007-06-20 10:49 ` [PATCH 0/2] Performance counter allocator separation Björn Steinbrink
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=20070622071354.GA20506@atjola.homenet \
--to=b.steinbrink@gmx.de \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=eranian@hpl.hp.com \
--cc=levon@movementarian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oprofile-list@lists.sourceforge.net \
--cc=perfmon@napali.hpl.hp.com \
--cc=wcohen@redhat.com \
/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®