[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091211110225.GA20831@elte.hu>
Date: Fri, 11 Dec 2009 12:02:25 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Will Deacon <will.deacon@....com>
Cc: 'Jamie Iles' <jamie.iles@...ochip.com>,
linux-kernel@...r.kernel.org,
Russell King <linux@....linux.org.uk>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 1/2] perf tools: allow building for ARM
* Will Deacon <will.deacon@....com> wrote:
> > From: linux-kernel-owner@...r.kernel.org [mailto:linux-kernel-owner@...r.kernel.org]
> > On Behalf Of Jamie Iles
> > Sent: 11 December 2009 10:31
> >
> > The implementation of the barriers depend on the CPU arch revision
> > which is defined in the kernel config. As the perf tools don't use
> > the kernel config, we don't know here what arch revision we're
> > building for. Perhaps we need a LINUX_ARM_ARCH parameter when
> > building for ARM so we can pick the correct one.
>
> Hi Jamie, Ingo,
>
> Surely a better way to proceed with this would be to build the perf
> tool as a side effect of building the kernel? That way the relevant
> definitions from system.h could be included directly and there would
> be no need to duplicate the architectural conditionals in perf.h.
Might make sense.
> I'm also working on perf-events for ARM and am using:
>
> #define rmb() asm volatile("mcr p15, 0, %0, c7, c10, 5" :: "r" (0) : "memory")
>
> This will work on v6 and v7 [although the dmb instruction is preferred
> here] cores.
Note that the codepath where it's used isnt very performance sensitive
(we call it about once per batch of event processing), so we could use
the broadest instruction that works on as many cores as possible - to
keep things simple.
Ingo
--
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