On Fri, Mar 04 2022 at 13:32, Peter Zijlstra wrote:
> On Mon, Feb 14, 2022 at 01:09:05PM +0200, Adrian Hunter wrote:
>> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>> index 82858b697c05..e8617efd552b 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -290,6 +290,15 @@ enum {
>> PERF_TXN_ABORT_SHIFT = 32,
>> };
>>
>> +/*
>> + * If supported, clockid value to select an architecture dependent hardware
>> + * clock. Note this means the unit of time is ticks not nanoseconds.
>> + * Requires ns_clockid to be set in addition to use_clockid.
>> + * On x86, this clock is provided by the rdtsc instruction, and is not
>> + * paravirtualized.
>> + */
>> +#define CLOCK_PERF_HW_CLOCK 0x10000000
>> +
>> /*
>> * The format of the data returned by read() on a perf event fd,
>> * as specified by attr.read_format:
>> @@ -409,7 +418,8 @@ struct perf_event_attr {
>> inherit_thread : 1, /* children only inherit if cloned with CLONE_THREAD */
>> remove_on_exec : 1, /* event is removed from task on exec */
>> sigtrap : 1, /* send synchronous SIGTRAP on event */
>> - __reserved_1 : 26;
>> + ns_clockid : 1, /* non-standard clockid */
>> + __reserved_1 : 25;
>>
>> union {
>> __u32 wakeup_events; /* wakeup every n events */
>
> Thomas, do we want to gate this behind this magic flag, or can that
> CLOCKID be granted unconditionally?
I'm not seeing a point in that flag and please define the clock id where
the other clockids are defined. We want a proper ID range for such
magically defined clocks.
We use INT_MIN < id < 16 today. I have plans to expand the ID space past
16, so using something like the above is fine.
Thanks,
tglx
