[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1314360781.11049.2.camel@twins>
Date: Fri, 26 Aug 2011 14:13:01 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Stephane Eranian <eranian@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>, mingo@...e.hu,
Robert Richter <robert.richter@....com>,
Vince Weaver <vweaver1@...s.utk.edu>
Subject: Re: [BUG] perf_event: semantic of PERF_SAMPLE_READ unclear
On Fri, 2011-08-26 at 14:02 +0200, Stephane Eranian wrote:
> On Thu, Aug 25, 2011 at 7:32 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Thu, 2011-08-25 at 19:19 +0200, Stephane Eranian wrote:
> >> But the difficulty is that
> >> we cannot grab any locks, not sure we need one given the call path.
> >
> > Nah we should be able to simply iterate all siblings and update them
> > in-place, since its group members they should all be co-scheduled. The
> > only difficulty is cross pmu group members..
> >
> Are we allowing event from different PMU to be in the same event group?
> If so, is that useful?
We allow software events, which can always be scheduled, to be part of a
hardware group. We don't allow mixing of different hardware pmus.
Allowing a software event is useful if for example the hardware pmu
doesn't have a sampling interrupt.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists