linux-kernel - Re: [PATCH 0/26] oprofile: Performance counter multiplexing

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]

Date:	Thu, 6 Aug 2009 10:31:52 +0300
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Robert Richter <robert.richter@....com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Paul Mackerras <paulus@...ba.org>,
	LKML <linux-kernel@...r.kernel.org>,
	oprofile-list <oprofile-list@...ts.sourceforge.net>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/26] oprofile: Performance counter multiplexing

Hi Robert,

On Wed, Aug 5, 2009 at 3:35 PM, Robert Richter<robert.richter@....com> wrote:
> The question is more if it makes sense. It's new to me dropping
> user/kernel interfaces that are in use and forcing its developers to
> rewrite their code. Oprofile is actively developed and in many
> distros. It supports architectures perfcounters doesn't. So, what do
> you want?

Maybe we can keep the ABIs in place but use a common machinery under
the hood for both perf and oprofile? That said, I do expect oprofile
ABIs to be special meaning that there's probably not a whole lot users
other than the oprofile user-space tool? So if do convert the
user-space tool to use sys_perf_counter_open() and put the in-kernel
oprofile code into deep-maintenance mode, maybe we can eventually get
rid of it?

That said, the lack of architecture support for perf is definitely a
blocker here...

On Wed, Aug 5, 2009 at 3:35 PM, Robert Richter<robert.richter@....com> wrote:
> And why not having more than one profiling subsystem in the kernel? I
> see also more than one type of car on the street though all of them
> have 4 wheels.

Well, so far I've only had bad experiences with duplicate
functionality in the kernel be it a core kernel subsystem like slab or
a device driver (broadcom and e100 come to mind). The problem is that
you fragment tester and developer base and end up with a different set
of bugs for each of the duplicate components causing more work than
necessary. And what eventually happens is that you have only one
component that's under active development but you can't get rid of the
less active ones because people depend on them and the active one has
corner case bugs that just don't get fixed.

                        Pekka
--
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/