Re: [rfc 1/3] perf, x86: P4 PMU - describe config format

From: Cyrill Gorcunov
Date: Fri Nov 26 2010 - 06:58:53 EST


On 11/26/10, Stephane Eranian <eranian@xxxxxxxxxx> wrote:
> On Fri, Nov 26, 2010 at 12:32 PM, Cyrill Gorcunov <gorcunov@xxxxxxxxxx>
> wrote:
>> On Fri, Nov 26, 2010 at 2:14 PM, Cyrill Gorcunov <gorcunov@xxxxxxxxxx>
>> wrote:
>>> Stephane, this is a misprint, I'll update this comments on format
>>> (giod catch btw!). in real low 32 bits are considered as cccr in ht
>>> mode. wait a bit, i'll post update.
>>>
>>> On 11/26/10, Stephane Eranian <eranian@xxxxxxxxxx> wrote:
>> ...
>>>>> + * Low 32 bits
>>>>> + * -----------
>>>>> + * 0-6: P4_PEBS_METRIC enum
>>>>> + * 7-11: reserved
>>>>> + * 12: Active thread
>>>>
>>>> I don't understand bit 12. In the actual register, it
>>>> corresponds to the enable bit. Seems you're overriding
>>>> its usage. Do I interpret this as saying: 0 = enable when
>>>> running on thread0, 1=monitoring when running on thread1?
>>>> And if I don't care?
>> ...
>> I believe it simply escaped quilt refresh somehow. Here is the 'refreshed'
>> copy (note the low bits 12-19 updated here).
>> ---
>> perf, x86: P4 PMU - describe config format v2
>>
>> Add description of .config in a sake of RAW events.
>> At least this should bring some light to those who
>> will be reading this code.
>>
>> Signed-off-by: Cyrill Gorcunov <gorcunov@xxxxxxxxxx>
>> CC: Lin Ming <ming.m.lin@xxxxxxxxx>
>> CC: Stephane Eranian <eranian@xxxxxxxxxx>
>> CC: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
>> ---
>> arch/x86/include/asm/perf_event_p4.h | 63
>> ++++++++++++++++++++++++++++++-----
>> 1 file changed, 55 insertions(+), 8 deletions(-)
>>
>> Index: linux-2.6.tip/arch/x86/include/asm/perf_event_p4.h
>> ===================================================================
>> --- linux-2.6.tip.orig/arch/x86/include/asm/perf_event_p4.h
>> +++ linux-2.6.tip/arch/x86/include/asm/perf_event_p4.h
>> @@ -744,14 +744,6 @@ enum P4_ESCR_EMASKS {
>> };
>>
>> /*
>> - * P4 PEBS specifics (Replay Event only)
>> - *
>> - * Format (bits):
>> - * 0-6: metric from P4_PEBS_METRIC enum
>> - * 7 : reserved
>> - * 8 : reserved
>> - * 9-11 : reserved
>> - *
>> * Note we have UOP and PEBS bits reserved for now
>> * just in case if we will need them once
>> */
>> @@ -788,5 +780,60 @@ enum P4_PEBS_METRIC {
>> P4_PEBS_METRIC__max
>> };
>>
>> +/*
>> + * Notes on internal configuration of ESCR+CCCR tuples
>> + *
>> + * Since P4 has quite the different architecture of
>> + * performance registers in compare with "architectural"
>> + * once and we have on 64 bits to keep configuration
>> + * of performance event, the following trick is used.
>> + *
>> + * 1) Since both ESCR and CCCR registers have only low
>> + * 32 bits valuable, we pack them into a single 64 bit
>> + * configuration. Low 32 bits of such config correspond
>> + * to low 32 bits of CCCR register and high 32 bits
>> + * correspond to low 32 bits of ESCR register.
>> + *
>> + * 2) The meaning of every bit of such config field can
>> + * be found in Intel SDM but it should be noted that
>> + * we "borrow" some reserved bits for own usage and
>> + * clean them or set to a proper value when we do
>> + * a real write to hardware registers.
>> + *
>> + * 3) The format of bits of config is the following
>> + * and should be either 0 or set to some predefined
>> + * values:
>> + *
>> + * Low 32 bits
>> + * -----------
>> + * 0-6: P4_PEBS_METRIC enum
>> + * 7-11: reserved
>> + * 12: reserved (Enable)
>> + * 13-15: reserved (ESCR select)
>> + * 16-17: Active Thread
>
> HW has the active thread bits reserved to 0x3.
> what about you? If not, then explain what they
> mean.
>
hm, not sure i follow, hw allows you to pass any of 4 values for that
field, so i simply pass it to kernel and then propagate to real cccr
register. if machine is not ht capable it might be a problem, but i
left it to a caller to set proper thread value here. i believe that
you read cccr spec for non-ht machine while ht machine has a bit more
flags to set.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/