[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100118172935.GM10364@nowhere>
Date: Mon, 18 Jan 2010 18:29:37 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Stephane Eranian <eranian@...gle.com>,
linux-kernel@...r.kernel.org, mingo@...e.hu, paulus@...ba.org,
davem@...emloft.net, perfmon2-devel@...ts.sf.net, eranian@...il.com
Subject: Re: [PATCH] perf_events: improve x86 event scheduling (v5)
On Mon, Jan 18, 2010 at 06:13:26PM +0100, Peter Zijlstra wrote:
> On Mon, 2010-01-18 at 17:51 +0100, Frederic Weisbecker wrote:
>
> > Right hw_perf_enable/disable have no action on breakpoint events.
> > These were somehow considered as software events until now.
> >
> > That raises the question: why perf_disable() only takes care
> > of hardware events? Very few software events can trigger
> > between perf_disable() and perf_enable() sections though.
> >
> > May be I should handle breakpoints there.
>
> OK, so maybe I'm not understanding the breakpoint stuff correctly, why
> is it modeled as a software pmu? It has resource constraints like a
> hardware pmu.
It doesn't use the software pmu, it uses its own. But what kind
of properties can it share with other hardware events?
It has constraints that only need to be checked when we register
the event. It has also constraint on enable time but nothing
tricky that requires an overwritten group scheduling.
And moreover it has no internal counters, it sensibly behaves
much like a software pmu by just triggering events.
--
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