All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [PATCH 0/9] oprofile, perf, x86: introduce new functions to reserve perfctrs
Date: Thu, 11 Mar 2010 13:47:16 +0100	[thread overview]
Message-ID: <20100311124716.GH31354@elte.hu> (raw)
In-Reply-To: <1268308081.5037.14.camel@laptop>


* Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2010-03-04 at 18:59 +0100, Peter Zijlstra wrote:
> > On Thu, 2010-03-04 at 16:22 +0100, Robert Richter wrote:
> > > This patch set improves the perfctr reservation code. New functions
> > > are available to reserve a counter by its index only. It is no longer
> > > necessary to allocate both msrs of a counter which also improves the
> > > code and makes it easier.
> > > 
> > > For oprofile a handler is implemented that returns an error now if a
> > > counter is already reserved by a different subsystem such as perf or
> > > watchdog. Before, oprofile silently ignored that counter. Finally the
> > > new reservation functions can be used to allocate special parts of the
> > > pmu such as IBS, which is necessary to use IBS with perf too.
> > > 
> > > The patches are available in the oprofile tree:
> > > 
> > >  git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git core
> > > 
> > > If there are no objections, I suggest to merge it into the
> > > tip/perf/core too, maybe after pending patches went in. If there are
> > > already conflicts, I will do the merge for this.
> > 
> > Right, so cleaning up that reservation code is nice, but wouldn't it be
> > much nicer to simply do away with all that and make everything use the
> > (low level) perf code?
> 
> Alternatively, could we maybe further simplify this reservation into:
> 
> int  reserve_pmu(void);
> void release_pmu(void);
> 
> And not bother with anything finer grained.

Yeah, that looks quite a bit simpler.

It's all about making it easier to live with legacies anyway - all modern 
facilities will use perf events to access the PMU.

	Ingo

  reply	other threads:[~2010-03-11 12:47 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
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 [this message]
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=20100311124716.GH31354@elte.hu \
    --to=mingo@elte.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oprofile-list@lists.sourceforge.net \
    --cc=peterz@infradead.org \
    --cc=robert.richter@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.