linux-kernel - Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events

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]

Date:	Tue, 16 Oct 2012 14:21:38 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Robert Richter <robert.richter@....com>
Cc:	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Arun Sharma <asharma@...com>,
	Anton Blanchard <anton@....ibm.com>,
	Paul Mackerras <paulus@...ba.org>, mpjohn@...ibm.com,
	linuxppc-dev@...abs.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events

On Tue, Oct 16, 2012 at 12:08 PM, Robert Richter <robert.richter@....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
>
--
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/