linux-kernel - Re: [patch] Performance Counters for Linux, v4

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:	Sat, 17 Jan 2009 00:11:39 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Maynard Johnson <maynardj@...ibm.com>
Cc:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Andi Kleen <andi@...stfloor.org>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephane Eranian <eranian@...glemail.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	Robert Richter <robert.richter@....com>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Anvin <hpa@...or.com>,
	"David S. Miller" <davem@...emloft.net>,
	perfctr-devel@...ts.sourceforge.net
Subject: Re: [patch] Performance Counters for Linux, v4

* Maynard Johnson <maynardj@...ibm.com> wrote:

> > Over time, it seems clear that we will see multi-core processor 
> > designs with increasingly large uncore/nest facilities, so this could 
> > become more and more of an issue.

> Ingo, I'll add my voice to the chorus here.  To reiterate the point, 
> some PMUs count events that are external to the processor cores, and 
> these events cannot be attributed to any one particular CPU -- and 
> certainly not to a particular pid.  The current interface has a 
> restriction that the user cannot pass -1 for both pid and cpu.  But it 
> seems to me that's exactly what would be needed for such off-core 
> events.  Can this feature fit in with the current interface or is some 
> sort of extension needed?

They fit in just fine, they just will have constraints that dont allow 
their scheduling in a conflicting way. I.e. you'll only be able to occupy 
it from a single counter per physical package - but otherwise it still 
behaves like a normal counter if you define a single such counter per 
physical package, as a percpu counter. (they dont make much sense as task 
counters)

Btw., those kind of constraints make them quite noisy and hard to 
interpret as well - because they summarize per physical package 
characteristics (of up to 8 logical CPUs on Nehalem for example) and 
cannot be tied to tasks easily.

I'm not dismissing them entirely: they do give an overview of "all stuff 
that happens" at that level, and they do show a few things that is 
obviously tied to the 'uncore' of a CPU (the cache, the memory interlink, 
etc.), which cannot be provided by the normal PMCs - but they are too 
highlevel to really be useful for finegrained analysis and for eventing.

In any case, despite their limitations they can still be provided just 
fine, and any limitations they have is an inherent limitation of those 
hardware counters, not of the perfcounters framework.

	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/