[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1265241793.24455.1647.camel@laptop>
Date: Thu, 04 Feb 2010 01:03:13 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Stephane Eranian <eranian@...gle.com>
Cc: Ingo Molnar <mingo@...e.hu>, Paul Mackerras <paulus@...ba.org>,
"Metzger, Markus T" <markus.t.metzger@...el.com>,
lkml <linux-kernel@...r.kernel.org>,
Robert Richter <robert.richter@....com>,
"David S. Miller" <davem@...emloft.net>,
Jamie Iles <jamie.iles@...ochip.com>,
Paul Mundt <lethal@...ux-sh.org>,
Arjan van de Ven <arjan@...radead.org>,
"H. Peter Anvin" <hpa@...or.com>, perfmon2-devel@...ts.sf.net
Subject: Re: [RFC][PATCH] perf_events, x86: PEBS support
On Thu, 2010-02-04 at 00:51 +0100, Stephane Eranian wrote:
> On Thu, Feb 4, 2010 at 12:50 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Wed, 2010-02-03 at 15:40 +0100, Peter Zijlstra wrote:
> >>
> >> If only they would reset the counter on overflow instead of on record,
> >> that would solve quite a few issues I imagine.
> >
> > So I tried enabling the regular PMC overflow interrupt and reprogramming
> > the counter from that, but touching the counter seems to destroy the
> > PEBS assist, so much for that idea.
> >
> Yes, you have to leave the INT bit off, otherwise you get an
> interrupt for each overflow, thus you lose the buffer advantage.
Well sure, but that's not the point. I was thinking that if we need to
do single event pebs anyway, we might as well try to reprogram on the
PMC overflow interrupt instead of on the PEBS overflow and curb some of
that drift.
Also, it makes keeping the event count value a lot easier. But alas.
--
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