Re: [PATCH V2 02/11] perf/x86: Add support for TSC as a perf event clock

[Thomas Gleixner]

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