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

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

Message-Id: <20081204.235747.43111785.davem@davemloft.net>
Date:	Thu, 04 Dec 2008 23:57:47 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	mingo@...e.hu
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

From: Ingo Molnar <mingo@...e.hu>
Date: Fri, 5 Dec 2008 08:03:29 +0100

> 
> * Ingo Molnar <mingo@...e.hu> wrote:
> 
> > This can be done in a very natural way with our abstraction, and the 
> > "hello.c" example happens to do exactly that:
> 
> multiple people pointed out that we have not posted hello.c :-/

Because it's completely not providing the facility.  This is not how
people want to use the performance counters at all.

And it doesn't even do what Paulus said is necessary, he said:

--------------------
> One thing that this sort of thing can't do is to get values from 
> multiple counters that correlate with each other.  For instance, we 
> would often want to count, say, L2 cache misses and instructions 
> completed at the same time, and be able to read both counters at very 
> close to the same time, so that we can measure average L2 cache misses 
> per instruction completed, which is useful.
--------------------

And if you read one counter then read the other as seperate operations,
you get extra events in there as a side effect of going back into
userspace between the two reads.

Nobody wants that, it's inaccurate and if you're looking for if one
event happens at all it's not only inaccurate it's useless if the
reads trigger that counter event.  Also, correlation has other
meanings.

What people want is blocking on overflow events, and a monitoring task
or thread doing all of the tricky control register management and task
inspection.

I mean look at some of the test cases and sample programs in the PAPI
and perfmon2 librarys, that stuff is extremely cool and this proposal
cannot do half of that stuff correctly.
--
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/