linux-kernel - Re: [patch 0/3] [Announcement] Performance Counters for Linux

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: <20081205132512.GA18786@elte.hu>
Date:	Fri, 5 Dec 2008 14:25:12 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	David Miller <davem@...emloft.net>
Cc:	paulus@...ba.org, tglx@...utronix.de, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org,
	eranian@...glemail.com, dada1@...mosbay.com,
	robert.richter@....com, arjan@...radead.org, hpa@...or.com,
	a.p.zijlstra@...llo.nl, rostedt@...dmis.org
Subject: Re: [patch 0/3] [Announcement] Performance Counters for Linux

* David Miller <davem@...emloft.net> wrote:

> > > Isn't it two separate read() calls to read the two counters?  If 
> > > so, the only way the two values are actually going to correspond to 
> > > the same point in time is if the task being monitored is stopped.  
> > > In which case the monitoring task needs to use ptrace or something 
> > > similar in order to make sure that the monitored task is actually 
> > > stopped.
> > 
> > It doesnt matter in practice.
> 
> Yes it DOES!
> 
> If I want to know if a code block triggers event X or Y, and your read 
> call triggers one of those events, I can't figure out the answer to my 
> profiling problem.

( this misunderstanding of yours has been cleared up in a later mail: 
  reading a counter causes events in the monitoring context, not in the
  monitored context. )

> That is completely fundamental to all of this.  And this is why this 
> proposal is a non-workable solution.
> 
> 
> > Also, look at our code: we buffer notification events and do not have 
> > to stop the thread for recording the context information.
> 
> But that's what monitoring libraries want, they want to stop the task 
> and inspect it.
> 
> Look at the PAPI library.  If you can't implement what that thing 
> provides, all the real users of profiling information can't use this 
> stuff.

We have looked, and the PAPI library can be implemented on top of our 
system call as well - just like it was implemented on top of the perfctr 
driver and like it was implemented ontop of "perfmon-full".

PAPI is a relatively simple wrapper around OS level performance counter 
facilities. Both the high level counter abstraction 
(PAPI_start_counters() & friends) and the low level PAPI abstraction 
(PAPI event sets, PAPI_attach/detach) can be readily implemented via the 
use of our performance counter subsystem facilities. (In addition to all 
the facilities around PAPI event enumeration.)

PAPI has about 100 functions - if you think our design does not fit it 
for some fundamental reason then please point out exactly which 
functionality (which PAPI function call) cannot be done.

Perfmon needlessly complicated their design by exposing user-space to a 
'performance counter context' and other lowlevel details that should not 
and must not be handled at the ABI level. The PAPI interfaces do not 
force that design choice in any way. It's a plain unnecessary 
complication that permeates the whole perfmon code.

	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/