linux-kernel - Re: [announce] Performance Counters for Linux, v6

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: <7c86c4470901260855y4431a11fu8d6546160fd274c6@mail.gmail.com>
Date:	Mon, 26 Jan 2009 17:55:58 +0100
From:	stephane eranian <eranian@...glemail.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Eric Dumazet <dada1@...mosbay.com>,
	Robert Richter <robert.richter@....com>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Anvin <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>,
	Mike Galbraith <efault@....de>,
	"perfmon2-devel@...ts.sourceforge.net" 
	<perfmon2-devel@...ts.sourceforge.net>,
	Papi <ptools-perfapi@...utk.edu>
Subject: Re: [announce] Performance Counters for Linux, v6

On Mon, Jan 26, 2009 at 4:17 PM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * stephane eranian <eranian@...glemail.com> wrote:
>
>> Hi,
>>
>>  Corey brings up an interesting problem which I wanted to comment on.
>>
>> The current proposal hinges on the idea that by interpreting a single
>> value the kernel can understand what the user wants to measure. For
>> instance, if I pass type=0, then the kernel understands I want to
>> measure CPU_CYCLES. Given that the number of events and their unit mask
>> combinations can be large, the proposal also provides a "raw" mode,
>> where the content of the type field is interpreted as the raw value to
>> put into a register.
>>
>> This is where there is an issue because with several PMU models,
>> including on X86, using the raw bit + 64 value is not enough to figure
>> out what the user wants to measure. This happens when the PMU has more
>> than counters. Thus, interpreting each raw value has the event code may
>> be wrong. To remain on familiar territory, the Nehalem uncore PMU has an
>> opcode matcher register, that uses a 64-bit value. On AMD64 Family 10h,
>> you have IBS. But I could give examples on Itanium with opcode matchers,
>> range restrictions. Corey provided other examples for Power. The API has
>> to provide a way to express what the raw value is meant for: counter,
>> matcher, filter...
>
> this can be done in a number of ways (in order of increasing levels of
> abstraction):
>
> - the raw type is kept wide enough. Paul already requested the raw type
>  to be widened to 128 bits to express certain PowerPC features.

Yes, 1 bit is not enough. With 128 that would be enough to encode all
the resources I can think of for existing Itanium, X86.

But then, I think fields would have to be renamed to make it clearer.
Raw would denote a type of resource and the current type field
could be renamed 'code' or 'val' or 'id' which reflects more what the
content actually would be.

As for Netburst, both CCCR and ESCR only use the bottom 32-bit so they
could be stuffed into the 64-bit 'type' field. But that would not work if a PMU
were to require wider values. Those values are part of the event encoding and
should not be considered optional nor attributes. That is why using a separate
call to program the second value does not seem appropriate to me.

>
> - or the PMU capability is expressed as a special counter type (if it's
>  useful enough) - and then either the write() method or ioctl is extended
>  to express attributes we want to set/change while a counter is running.
>
> - or the highest level counter / hw event data type is extended with new
>  attribute field(s).
>
> My feeling is that we generally want such hw features to start small -
> i.e. at the raw type level initially. Then we can allow them to climb the
> ladder, if they prove their utility in practice. We've got space reserved
> in the ABI to allow for growth like this.
>
>        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/