[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140114105721.GU7572@laptop.programming.kicks-ass.net>
Date: Tue, 14 Jan 2014 11:57:21 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Vince Weaver <vincent.weaver@...ne.edu>
Cc: Will Deacon <will.deacon@....com>,
Chad Paradis <chad.paradis@...t.maine.edu>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Paul Mackerras <paulus@...ba.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Stephane Eranian <eranian@...il.com>
Subject: Re: [patch/rfc] perf on raspberry-pi without overflow interrupt
On Mon, Jan 13, 2014 at 11:55:17PM -0500, Vince Weaver wrote:
> On Fri, 10 Jan 2014, Peter Zijlstra wrote:
>
> > On Thu, Jan 09, 2014 at 11:08:47PM -0500, Vince Weaver wrote:
> > > On Thu, 9 Jan 2014, Will Deacon wrote:
> > >
> > > > I'd rather see it in the generic code if at all possible. Maybe we could add
> > > > a flags field to perf_pmu_register?
> > >
> > > I can look into adding the check in generic code.
> >
> > Adding something like this to the generic code would mean adding a
> > struct pmu capabilities field and visiting all existing PMU
> > implementations to properly fill this out.
>
> I don't see an existing pmu capabilities struct... or do you mean
> coming up with one?
Yeah, adding one.
> Would it only hold an "overflow_interrupt_available" flag, or are
> there other generic capabilities it would be handy to know about?
Possible (other) flags could be:
PMU_HAS_INT -- would allow sampling events
PMU_HAS_PRECISE -- would allow any ::precise value
PMU_HAS_FILTER -- would allow all os/user/etc. flags
> > There's a number of hardware PMU implementations that do not have an
> > interrupt and would need to set this flag.
>
> Well that can be added gradually, right? Things wouldn't get any worse if
> we add a generic check without auditing all code, things will just behave
> the same as before for those architectures.
Right, doing a sweep once every so often is useful to find more patterns
though.
> There is some subtlety here though. On ARM (or at least rasp-pi) the
> overflow hardware is there, just no interrupt is hooked up. So things
> like counter overflow are handled as long as overflows aren't faster than
> context switch time. It's just sampled events aren't possible.
>
> On architectures without overflow support at all (I've had such hardware;
> some SPARC machines, the Playstation 3 hypervisor) then counter overflow
> isn't possible without a periodic timer (sort of like what is done with
> Intel uncore). Is that something that should be in generic code too?
Maybe yeah, if there's enough replication of this it certainly makes
sense to lift it into generic code.
--
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