linux-kernel - Re: [PATCH 0/3] Generalise ARM perf-events backend for oprofile

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1282727242.5727.7.camel@e102144-lin.cambridge.arm.com>
Date:	Wed, 25 Aug 2010 10:07:22 +0100
From:	Will Deacon <will.deacon@....com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Matt Fleming <matt@...sole-pimps.org>,
	linux-kernel@...r.kernel.org,
	Robert Richter <robert.richter@....com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Russell King <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, linux-sh@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH 0/3] Generalise ARM perf-events backend for oprofile

Ben,

On Wed, 2010-08-25 at 02:41 +0100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-08-23 at 06:57 -0400, Christoph Hellwig wrote:
> > On Mon, Aug 23, 2010 at 11:46:18AM +0100, Matt Fleming wrote:
> > > The perf-events backend for OProfile that Will Deacon wrote in
> > > 8c1fc96f6fd1f361428ba805103af0d0eee65179 ("ARM: 6072/1: oprofile: use
> > > perf-events framework as backend") is of use to more architectures
> > > than just ARM. Move the code into drivers/oprofile/ so that SH can use
> > > it instead of the nearly identical copy of its OProfile code.
> >
> > Nice, I didn't know such a backend already existed.  Now that you
> > have made it generic we should aim towards making it the only oprofile
> > backend and getting rid of all the duplication.
> 
> Even better would be to do the surgery at a higher level and provide the
> oprofile API without the oprofile buffer management. My experience is
> that it doesn't scale, and on heavily threaded large SMP setup, there is
> an enormous amount of time wasted contending on the global oprofile
> buffer mutex.
> 
Ideally, the OProfile userspace tools would talk native perf and we
could do away with oprofilefs and the oprofile buffer altogether.
Compatibility with the old [read current] OProfile tools can be
maintained using these patches until the API is deprecated.

Or is that a bit too optimistic? :)

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/