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: <20090703082734.GE21833@elte.hu>
Date:	Fri, 3 Jul 2009 10:27:34 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Jaswinder Singh Rajput <jaswinder@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/6 -tip] perf stat: treat same behaviour for all
	CYCLES and CLOCKS


* Paul Mackerras <paulus@...ba.org> wrote:

> Ingo Molnar writes:
> 
> > Other 'compound' events might be possible too: for example a new 
> > cache-hits field could be is cache-refs minus cache-misses.
> 
> Hmmm, on the MPC7450 family there are events for cache-hits and 
> cache-misses, so there it would be nice to be able to ask for 
> cache-refs and have it compute cache-hits plus cache-misses.

Yes. I think the API is structured enough so that user-space knows 
enough about the meaning of the events here. We can certainly 
stipulate this rule:

	refs == hits + misses

And if the kernel returns -ENODEV for a particular component 
user-space can fall back using the other two events.

I.e. this would allow transparent support for all 3 permutations:

	hw has refs and hits
	hw has refs and misses
	hw has hits and misses

For sampling it's a tiny bit tricky but still doable:j a compound 
counter could still sample because we handle weighted samples 
throughout the tools and negative weight can be subtraced.

Intuitive annotation output would have to be thought out for this as 
entries/function could go negative statistically.

> > I.e. the simplest model for 'compound' events would be:
> > 
> >   X = A / B
> >   X = A - B
> >   X = A + B
> > 
> > We could list them in the event table, with a flag that 
> > specifies which arithmetic operation connects two 'atomic' 
> > counters.
> > 
> > Then the adding of a new compound event would only be the matter 
> > of adding one more line to the event table.
> 
> Sounds nice.  If we do this we should ensure that the two events 
> get put into one group if possible.

Correct. Are you interested in adding this, so that it fits the 
MPC7450 family perfectly?

	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

Powered by Openwall GNU/*/Linux Powered by OpenVZ