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] [day] [month] [year] [list]

Date:	Sat, 17 Jan 2009 10:53:39 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>, 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, maynardj@...ibm.com
Subject: Re: [patch] Performance Counters for Linux, v4

On Sat, Jan 17, 2009 at 12:26:15PM +1100, Paul Mackerras wrote:
> Corey Ashford writes:
> 
> > 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.
> 
> Those nest events still get counted on counters that are in the CPU
> core, right? 

Nope, Nehalem uncore counters are separate per socket. The uncore
has its own counters.

You can program them to interrupt some fixed CPU thread (but 
it's not necessarily the thread who caused the event) or all CPU threads
on the socket.

I found these semantics quite hard to fit into oprofile too because
it also has too many per cpu events assumptions.

> So that sounds like they can be counted by one or more
> per-cpu perf_counter instances.  That means that you're measuring them
> across all processes.  Does it make any sense to try to attribute
> those events to individual processes?  How would one do that?

You can't (except by forcing only a single thread to run on 
the socket). The hardware doesn't know otherwise.

perfmon3 has a concept of counters which are system wide.
While that's also not a 100% match on a multi socket system
it's better than assigning it to some random CPU.

> 
> Clearly, something has to know enough about the system topology to
> know how many counters are needed and which (virtual) cpus they should

Hmm you want to create new virtual cpus for this?

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/