Messages in this thread | | | Date | Fri, 26 Nov 2010 14:54:39 +0100 | Subject | Re: [rfc 1/3] perf, x86: P4 PMU - describe config format | From | Stephane Eranian <> |
| |
On Fri, Nov 26, 2010 at 2:50 PM, Cyrill Gorcunov <gorcunov@openvz.org> wrote: > On Fri, Nov 26, 2010 at 4:10 PM, Stephane Eranian <eranian@google.com> wrote: >> On Fri, Nov 26, 2010 at 2:04 PM, Cyrill Gorcunov <gorcunov@openvz.org> wrote: >>> On 11/26/10, Stephane Eranian <eranian@google.com> wrote: >>>> On Fri, Nov 26, 2010 at 12:58 PM, Cyrill Gorcunov <gorcunov@openvz.org> >>>> wrote: >>>>> On 11/26/10, Stephane Eranian <eranian@google.com> wrote: >>>>>> On Fri, Nov 26, 2010 at 12:32 PM, Cyrill Gorcunov <gorcunov@openvz.org> >>>>>> wrote: >>>>>>> On Fri, Nov 26, 2010 at 2:14 PM, Cyrill Gorcunov <gorcunov@openvz.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@google.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@openvz.org> >>>>>>> CC: Lin Ming <ming.m.lin@intel.com> >>>>>>> CC: Stephane Eranian <eranian@google.com> >>>>>>> CC: Peter Zijlstra <peterz@infradead.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?
From the manual:
00 — None. Count only when neither logical processor is active. 01 — Single. Count only when one logical processor is active (either 0 or 1). 10 — Both. Count only when both logical processors are active. 11 — Any. Count when either logical processor is active.
In per-thread mode, you won't hit 00. I suspect you want to disallow 01, 10 (or CAP_SYS_ADMIN). Otherwise, you want to force 11, i.e., can't figure out what's going on in the other HT thread. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |