Message-ID: <AANLkTi=jLNwKOqUKay9c9aLVd_7do5n1iCYEUkOfS7G+@mail.gmail.com>
Date:	Fri, 26 Nov 2010 16:50:40 +0300
From:	Cyrill Gorcunov <gorcunov@...nvz.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	ming.m.lin@...el.com, peterz@...radead.org
Subject: Re: [rfc 1/3] perf, x86: P4 PMU - describe config format

On Fri, Nov 26, 2010 at 4:10 PM, Stephane Eranian <eranian@...gle.com> wrote:
> On Fri, Nov 26, 2010 at 2:04 PM, Cyrill Gorcunov <gorcunov@...nvz.org> wrote:
>> On 11/26/10, Stephane Eranian <eranian@...gle.com> wrote:
>>> On Fri, Nov 26, 2010 at 12:58 PM, Cyrill Gorcunov <gorcunov@...nvz.org>
>>> wrote:
>>>> On 11/26/10, Stephane Eranian <eranian@...gle.com> wrote:
>>>>> On Fri, Nov 26, 2010 at 12:32 PM, Cyrill Gorcunov <gorcunov@...nvz.org>
>>>>> wrote:
>>>>>> On Fri, Nov 26, 2010 at 2:14 PM, Cyrill Gorcunov <gorcunov@...nvz.org>
>>>>>> 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@...gle.com> 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@...nvz.org>
>>>>>> CC: Lin Ming <ming.m.lin@...el.com>
>>>>>> CC: Stephane Eranian <eranian@...gle.com>
>>>>>> CC: Peter Zijlstra <peterz@...radead.org>
>>>>>> ---
>>>>>>  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.
>>>>
>>> You're right, I missed Figure-30.29. So you honor the field. The counter
>>> won't count anything if the task is not running on the corresponding
>>> HT thread, then.
>>
>> no ;) p4 treat this field in different meaning in compare to others
>> perf archs. the condition is not 'where' but 'when'. ie you can
>> specify 'when' to run counter: if none therad is active, single any
>> thread is active, both threads are active and finally any thread is
>> active (which is exactly 0b11 in single thread machine). i know it's
>> weird ;)
>>
> That is weird indeed.
>
> I can see this being somewhat useful in per-cpu mode. But this is
> weird in per-thread mode. That means you will count in your thread
> (OS and HW) only when the other HW thread runs. I am wondering
> about the security implications of this. I suspect you'd have to
> disallow this mode in per-thread mode.

No, single thread mode means _any_ single thread is running,
Stephane I'll describe some more a bit later (as only reach home),
ok?
--
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/

Powered by blists - more mailing lists