All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: paulus <paulus@samba.org>
Cc: stephane eranian <eranian@googlemail.com>,
	Robert Richter <robert.richter@amd.com>,
	Will Deacon <will.deacon@arm.com>,
	Paul Mundt <lethal@linux-sh.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Lin Ming <ming.m.lin@intel.com>,
	Yanmin <yanmin_zhang@linux.intel.com>,
	Deng-Cheng Zhu <dengcheng.zhu@gmail.com>,
	David Miller <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [RFC][PATCH 0/8] perf pmu interface
Date: Wed, 16 Jun 2010 20:19:32 +0200	[thread overview]
Message-ID: <1276712372.1745.619.camel@laptop> (raw)
In-Reply-To: <20100616160027.590430763@chello.nl>

On Wed, 2010-06-16 at 18:00 +0200, Peter Zijlstra wrote:
> These patches prepare the perf code for multiple pmus (no user
> interface yet, Lin Ming is working on that). These patches remove all
> weak functions and rework the struct pmu interface.
> 
> The latter is inspired by the work Frederic is doing to to filter out
> IRQ contexts.
> 
> These patches are very prelimenary, they haven't seen a compiler yet and
> the last patch still needs sparc,ppc and arm converted.
> 
> But they patches seem to be in a good enough shape to see what people
> think..

Another idea I was kicking about was to push find_get_context()
partially into struct pmu, so that we can have context's per pmu.

For cpu-wide contexts its easy, for per-task contexts we need more
pointers in task_struct, so I was thinking of something like:

enum {
  perf_swevent_context = 0,
  perf_cpu_context,
#ifdef HW_BREAKPOINT
  perf_bp_context,
#endif
  perf_nr_task_context
};

struct task_struct {
  ...
  struct perf_event_context *perf_event_ctxs[perf_nr_task_context];
  ...
};

and have add for loops over the struct pmu list for the cpu-wide
contexts and for loops over perf_nr_task_context for the task contexts.

It would add some extra code to the hot-paths, but its the best I can
come up with.

  parent reply	other threads:[~2010-06-16 18:19 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-16 16:00 [RFC][PATCH 0/8] perf pmu interface Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 1/8] perf, x86: Fix Nehalem PMU quirk Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 2/8] perf: deconstify struct pmu Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 3/8] perf: register pmu implementations Peter Zijlstra
2010-06-16 16:45   ` Robert Richter
2010-06-16 17:03   ` Frederic Weisbecker
2010-06-16 17:48     ` Peter Zijlstra
2010-06-16 18:10       ` Peter Zijlstra
2010-06-18  4:51       ` Frederic Weisbecker
2010-06-17 23:31   ` Paul Mackerras
2010-06-18  8:40     ` Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 4/8] perf: Unindent labels Peter Zijlstra
2010-06-16 17:16   ` Frederic Weisbecker
2010-06-16 17:48     ` Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 5/8] perf: Reduce perf_disable() usage Peter Zijlstra
2010-06-16 16:52   ` Cyrill Gorcunov
2010-06-16 16:00 ` [RFC][PATCH 6/8] perf: Per PMU disable Peter Zijlstra
2010-06-16 17:48   ` Robert Richter
2010-06-16 17:58     ` Peter Zijlstra
2010-06-18  2:14   ` Frederic Weisbecker
2010-06-18  7:11     ` Peter Zijlstra
2010-06-22 16:21       ` Frederic Weisbecker
2010-06-22 17:09         ` Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 7/8] perf: Default PMU ops Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 8/8] perf: Rework the PMU methods Peter Zijlstra
2010-06-18  4:21   ` Frederic Weisbecker
2010-06-18  7:15     ` Peter Zijlstra
2010-06-22 16:26       ` Frederic Weisbecker
2010-06-22 17:10         ` Peter Zijlstra
2010-06-16 18:19 ` Peter Zijlstra [this message]
2010-06-18  4:35   ` [RFC][PATCH 0/8] perf pmu interface Frederic Weisbecker
2010-06-18  7:22     ` Peter Zijlstra

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=1276712372.1745.619.camel@laptop \
    --to=peterz@infradead.org \
    --cc=davem@davemloft.net \
    --cc=dengcheng.zhu@gmail.com \
    --cc=eranian@googlemail.com \
    --cc=fweisbec@gmail.com \
    --cc=gorcunov@gmail.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=robert.richter@amd.com \
    --cc=will.deacon@arm.com \
    --cc=yanmin_zhang@linux.intel.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.