[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131028125354.GB20814@mudshark.cambridge.arm.com>
Date: Mon, 28 Oct 2013 12:53:54 +0000
From: Will Deacon <will.deacon@....com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Vince Weaver <vincent.weaver@...ne.edu>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else
On Mon, Oct 28, 2013 at 10:00:49AM +0000, Peter Zijlstra wrote:
> On Mon, Oct 28, 2013 at 08:57:00AM +0000, Will Deacon wrote:
> > > Should other architectures be updated to? I just wanted to find out the
> > > rationale for this before I update the manpage to reflect the difference
> > > in behaviors between architectures.
> >
> > I don't want to be the `oddball' architecture (at least, not more than I am
> > already :), but I do find it tricky to follow the required semantics of perf
> > as opposed to `it happens to work this way', especially when so much of it
> > is buried in the various arch backends. So if somebody using the thing on
> > ARM has (what looks to me like) a valid issue, then I usually try and fix
> > it.
>
> Hurmph.. at least raise the issue for the other archs.
Yeah, sorry about that. I thought Stephane might take it forward (since he
was on the perfmon thread I linked to) and I did CC you on the patch.
While we're at it, there was another patch that I CC'd others on since it
might be wanted by other architectures too: cb2d8b342aa0 ("ARM: 7698/1:
perf: fix group validation when using enable_on_exec"). Basically, the
patch ensures that events that are set to enable on exec are included in
group validation, despite being in the OFF state at validation time.
Any thoughts on that?
Will
--
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