From: Andi Kleen <andi@firstfloor.org>
To: Robert Richter <robert.richter@amd.com>
Cc: Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
oprofile-list <oprofile-list@lists.sourceforge.net>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 3/9] oprofile, perf, x86: introduce new functions to reserve perfctrs by index
Date: Thu, 25 Mar 2010 20:33:18 +0100 [thread overview]
Message-ID: <20100325193318.GT20695@one.firstfloor.org> (raw)
In-Reply-To: <20100325155208.GI1585@erda.amd.com>
On Thu, Mar 25, 2010 at 04:52:08PM +0100, Robert Richter wrote:
> Andi,
>
> so far it does not seem this reservation patches will go upstream. So
> we still do not have a solution of how to share the pmu with perf. The
There's the current reservation
code which has some issues and is butt ugly, but does its job mostly.
The only real problem I have with it is that it doesn't support fixed counters.
That's not very hard to fix (patches posted), but of course requires
some basic cooperation from impartial maintainers. I think extending
it to other registers shouldn't also be that hard.
> current approach is a global pmu lock. I don't think this is a good
> solution and we already see questions on the oprofile mailing list why
> counters are not available to use. This will become much worse if perf
> is using counters permanently in the kernel (e.g. the perf nmi
> watchdog). This will make oprofile unusable.
NMI watchdog is not on by default luckily.
Anyways I don't really understand what the problem with just
allocating counters properly in perf_events like everyone else.
They need to do that anyways to cooperate with firmware or VMs using these
counters.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-03-25 19:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 15:22 [PATCH 0/9] oprofile, perf, x86: introduce new functions to reserve perfctrs Robert Richter
2010-03-04 15:22 ` [PATCH 1/9] perf, x86: reduce number of CONFIG_X86_LOCAL_APIC macros Robert Richter
2010-03-04 15:22 ` [PATCH 2/9] oprofile, perf, x86: do not allocate evntsel counter msr Robert Richter
2010-03-04 15:22 ` [PATCH 3/9] oprofile, perf, x86: introduce new functions to reserve perfctrs by index Robert Richter
2010-03-20 5:45 ` Andi Kleen
2010-03-25 15:52 ` Robert Richter
2010-03-25 19:33 ` Andi Kleen [this message]
2010-03-04 15:22 ` [PATCH 4/9] tsc, x86: use new perfctr reservation functions in tsc code Robert Richter
2010-03-04 15:22 ` [PATCH 5/9] perf, x86: use new perfctr reservation functions in perf code Robert Richter
2010-03-04 15:22 ` [PATCH 6/9] oprofile/x86: rework error handler in nmi_setup() Robert Richter
2010-03-04 15:22 ` [PATCH 7/9] oprofile/x86: return -EBUSY if counters are already reserved Robert Richter
2010-03-04 15:22 ` [PATCH 8/9] oprofile/x86: group IBS code Robert Richter
2010-03-04 15:22 ` [PATCH 9/9] oprofile/x86: implement perfctr reservation for IBS Robert Richter
2010-03-04 17:59 ` [PATCH 0/9] oprofile, perf, x86: introduce new functions to reserve perfctrs Peter Zijlstra
2010-03-11 11:48 ` Peter Zijlstra
2010-03-11 12:47 ` Ingo Molnar
2010-03-11 15:45 ` Robert Richter
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=20100325193318.GT20695@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oprofile-list@lists.sourceforge.net \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
--cc=tglx@linutronix.de \
/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