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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090804201109.GA21386@elte.hu>
Date:	Tue, 4 Aug 2009 22:11:09 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Robert Richter <robert.richter@....com>,
	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

* Arjan van de Ven <arjan@...radead.org> wrote:

> On Mon, 3 Aug 2009 13:22:20 +0200
> Ingo Molnar <mingo@...e.hu> wrote:
> > 
> > This new oprofile multiplexing mechanism really overlaps the PMU 
> > abstractions that perfcounters already provide, and i disagree 
> > with this general direction. The code you wrote is clean though 
> > so i've
> 
> is there any way that the oprofile interfaces can be written on 
> top of the low level perf infrastructure?

Everything 'can' be done - the question is, is that the best 
approach? The technically best interface to utilize perfcounters is 
not to whack it into the oprofile kernel code, but to minimally 
update the oprofile user-space code (the sample collection daemon) 
to use the sys_perf_counter_open() system call.

It is by far the most elegant solution and needs no kernel changes 
at all:

The oprofile daemon should open percpu sampling counters and create 
oprofile-compatible sample files. That way the rest of the oprofile 
user-space does not have to be touched at all. The raw event ids 
that oprofile knows about can be used in perfcounter parameters 
directly.

In such a mode of operation both oprofilefs and the dcookies syscall 
can be omitted completely - all of the kernel side oprofile code 
becomes mooted and pushed into legacy mode.

Is there any reason or oprofile property that makes this impossible 
or undesirable to do?

	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/