On Tue, Oct 16, 2012 at 12:08 PM, Robert Richter <robert.rich...@amd.com> wrote:
> Sukadev,
>
> On 15.10.12 17:55:34, Robert Richter wrote:
>> On 11.10.12 18:28:39, Sukadev Bhattiprolu wrote:
>> > + { .type = PERF_TYPE_HARDWARE, .config =
>> > PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
>> > + { .type = PERF_TYPE_HARDWARE, .config =
>> > PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
>> > + { .type = PERF_TYPE_HARDWARE, .config =
>> > PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
>> > + { .type = PERF_TYPE_HARDWARE, .config =
>> > PERF_COUNT_HW_STALLED_CYCLES_BRANCH },
>>
>> Instead of adding new hardware event types I would prefer to use raw
>> events in conjunction with sysfs, see e.g. the intel-uncore
>> implementation. Something like:
>>
In general, I don't like generic events and especially stall events. I
have not seen a clear definition of
what they mean. Without it, there is no way to understand how to map
them across architecture. If
the definition is too precise, you may not be able to find an exact
mapping. If the definition is to loose
then it is unclear what you are measuring.
Also this opens another can of worms which is that on some processors,
you may need more than
one event to encapsulate what the generic event is supposed to
measure. That means developing
a lot of code in the kernel to express and manage that. And of course,
you would not be able
to sample on those events (you cannot sample on a difference, for
instance). So all in all, I think
this is not a very good idea. You have to put this into the tool or a
library that auto-detects the
host CPU and programs the right set of events.
We've had that discussion many times. Just reiterating my personal
opinion on this.
>> $ find /sys/bus/event_source/devices/cpu/events/
>> ...
>> /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
>> /sys/bus/event_source/devices/cpu/events/stalled-cycles-load-store
>> /sys/bus/event_source/devices/cpu/events/stalled-cycles-instruction-fetch
>> /sys/bus/event_source/devices/cpu/events/stalled-cycles-branch
>> ...
>> $ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
>> event=0xff,umask=0x00
>>
>> Perf tool works then out-of-the-box with:
>>
>> $ perf record -e cpu/stalled-cycles-fixed-point/ ...
>
> I refer here to arch/x86/kernel/cpu/perf_event_intel_uncore.c (should
> be in v3.7-rc1 or tip:perf/core). See the INTEL_UNCORE_EVENT_DESC()
> macro and 'if (type->event_descs) ...' in uncore_type_init(). The code
> should be reworked to be non-architectural.
>
> PMU registration is implemented for a longer time already for all
> architectures and pmu types:
>
> /sys/bus/event_source/devices/*
>
> But
>
> /sys/bus/event_source/devices/*/events/
>
> exists only for a small number of pmus. Perf tool support of this was
> implemented with:
>
> a6146d5 perf/tool: Add PMU event alias support
>
> -Robert
>
> --
> Advanced Micro Devices, Inc.
> Operating System Research Center
>
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
