Re: [PATCH V4 4/8] perf/x86/intel/uncore: add new data structures for free running counters
On Sun, 14 Jan 2018, Thomas Gleixner wrote: > On Thu, 2 Nov 2017, kan.li...@intel.com wrote: > > +/* > > + * Free running counter is similar as fixed counter, except it is read-only > > + * and always active when the uncore box is powered up. > > + * > > + * Here are the rules which are used to encode the event for free running > > + * counter. > > + * - The event for free running counter has the same event code 0xff as > > + * the event for fixed counter. > > + * - The umask of the event starts from 0x10. The umask which is less > > + * than 0x10 is reserved for the event of fixed counter. > > + * - The free running counters can be divided into different types > > according > > + * to the MSR location, bit width or definition. The start point of the > > + * umask for different type has 0x10 offset. > > + * > > + * For example, there are three types of IIO free running counters on > > Skylake > > + * server, IO CLOCKS counters, BANDWIDTH counters and UTILIZATION counters. > > + * The event code for all the free running counters is 0xff. > > + * 'ioclk' is the first counter of IO CLOCKS. IO CLOCKS is the first type, > > + * which umask starts from 0x10. > > + * So 'ioclk' is encoded as event=0xff,umask=0x10 > > + * 'bw_in_port2' is the third counter of BANDWIDTH counters. BANDWIDTH is > > + * the second type, which umask starts from 0x20. > > + * So 'bw_in_port2' is encoded as event=0xff,umask=0x22 > > + */ > > +static inline unsigned int uncore_freerunning_idx(u64 config) > > +{ > > + return ((config >> 8) & 0xf); > > +} > > + > > +#define UNCORE_FREERUNNING_UMASK_START 0x10 > > +static inline unsigned int uncore_freerunning_type(u64 config) > > Groan. I asked that before that you please stop glueing defines right in > front of a function declaration w/o any visible space. Is it that hard to > read and address _ALL_ review comments? > > > +{ > > + return config >> 8) - UNCORE_FREERUNNING_UMASK_START) >> 4) & 0xf); > > +} > > Other than that this looks reasonable. Hit send to early: Reviewed-by: Thomas Gleixner
Re: [PATCH V4 4/8] perf/x86/intel/uncore: add new data structures for free running counters
On Sun, 14 Jan 2018, Thomas Gleixner wrote: > On Thu, 2 Nov 2017, kan.li...@intel.com wrote: > > +/* > > + * Free running counter is similar as fixed counter, except it is read-only > > + * and always active when the uncore box is powered up. > > + * > > + * Here are the rules which are used to encode the event for free running > > + * counter. > > + * - The event for free running counter has the same event code 0xff as > > + * the event for fixed counter. > > + * - The umask of the event starts from 0x10. The umask which is less > > + * than 0x10 is reserved for the event of fixed counter. > > + * - The free running counters can be divided into different types > > according > > + * to the MSR location, bit width or definition. The start point of the > > + * umask for different type has 0x10 offset. > > + * > > + * For example, there are three types of IIO free running counters on > > Skylake > > + * server, IO CLOCKS counters, BANDWIDTH counters and UTILIZATION counters. > > + * The event code for all the free running counters is 0xff. > > + * 'ioclk' is the first counter of IO CLOCKS. IO CLOCKS is the first type, > > + * which umask starts from 0x10. > > + * So 'ioclk' is encoded as event=0xff,umask=0x10 > > + * 'bw_in_port2' is the third counter of BANDWIDTH counters. BANDWIDTH is > > + * the second type, which umask starts from 0x20. > > + * So 'bw_in_port2' is encoded as event=0xff,umask=0x22 > > + */ > > +static inline unsigned int uncore_freerunning_idx(u64 config) > > +{ > > + return ((config >> 8) & 0xf); > > +} > > + > > +#define UNCORE_FREERUNNING_UMASK_START 0x10 > > +static inline unsigned int uncore_freerunning_type(u64 config) > > Groan. I asked that before that you please stop glueing defines right in > front of a function declaration w/o any visible space. Is it that hard to > read and address _ALL_ review comments? > > > +{ > > + return config >> 8) - UNCORE_FREERUNNING_UMASK_START) >> 4) & 0xf); > > +} > > Other than that this looks reasonable. Hit send to early: Reviewed-by: Thomas Gleixner
Re: [PATCH V4 4/8] perf/x86/intel/uncore: add new data structures for free running counters
On Thu, 2 Nov 2017, kan.li...@intel.com wrote: > +/* > + * Free running counter is similar as fixed counter, except it is read-only > + * and always active when the uncore box is powered up. > + * > + * Here are the rules which are used to encode the event for free running > + * counter. > + * - The event for free running counter has the same event code 0xff as > + * the event for fixed counter. > + * - The umask of the event starts from 0x10. The umask which is less > + * than 0x10 is reserved for the event of fixed counter. > + * - The free running counters can be divided into different types according > + * to the MSR location, bit width or definition. The start point of the > + * umask for different type has 0x10 offset. > + * > + * For example, there are three types of IIO free running counters on Skylake > + * server, IO CLOCKS counters, BANDWIDTH counters and UTILIZATION counters. > + * The event code for all the free running counters is 0xff. > + * 'ioclk' is the first counter of IO CLOCKS. IO CLOCKS is the first type, > + * which umask starts from 0x10. > + * So 'ioclk' is encoded as event=0xff,umask=0x10 > + * 'bw_in_port2' is the third counter of BANDWIDTH counters. BANDWIDTH is > + * the second type, which umask starts from 0x20. > + * So 'bw_in_port2' is encoded as event=0xff,umask=0x22 > + */ > +static inline unsigned int uncore_freerunning_idx(u64 config) > +{ > + return ((config >> 8) & 0xf); > +} > + > +#define UNCORE_FREERUNNING_UMASK_START 0x10 > +static inline unsigned int uncore_freerunning_type(u64 config) Groan. I asked that before that you please stop glueing defines right in front of a function declaration w/o any visible space. Is it that hard to read and address _ALL_ review comments? > +{ > + return config >> 8) - UNCORE_FREERUNNING_UMASK_START) >> 4) & 0xf); > +} Other than that this looks reasonable.
Re: [PATCH V4 4/8] perf/x86/intel/uncore: add new data structures for free running counters
On Thu, 2 Nov 2017, kan.li...@intel.com wrote: > +/* > + * Free running counter is similar as fixed counter, except it is read-only > + * and always active when the uncore box is powered up. > + * > + * Here are the rules which are used to encode the event for free running > + * counter. > + * - The event for free running counter has the same event code 0xff as > + * the event for fixed counter. > + * - The umask of the event starts from 0x10. The umask which is less > + * than 0x10 is reserved for the event of fixed counter. > + * - The free running counters can be divided into different types according > + * to the MSR location, bit width or definition. The start point of the > + * umask for different type has 0x10 offset. > + * > + * For example, there are three types of IIO free running counters on Skylake > + * server, IO CLOCKS counters, BANDWIDTH counters and UTILIZATION counters. > + * The event code for all the free running counters is 0xff. > + * 'ioclk' is the first counter of IO CLOCKS. IO CLOCKS is the first type, > + * which umask starts from 0x10. > + * So 'ioclk' is encoded as event=0xff,umask=0x10 > + * 'bw_in_port2' is the third counter of BANDWIDTH counters. BANDWIDTH is > + * the second type, which umask starts from 0x20. > + * So 'bw_in_port2' is encoded as event=0xff,umask=0x22 > + */ > +static inline unsigned int uncore_freerunning_idx(u64 config) > +{ > + return ((config >> 8) & 0xf); > +} > + > +#define UNCORE_FREERUNNING_UMASK_START 0x10 > +static inline unsigned int uncore_freerunning_type(u64 config) Groan. I asked that before that you please stop glueing defines right in front of a function declaration w/o any visible space. Is it that hard to read and address _ALL_ review comments? > +{ > + return config >> 8) - UNCORE_FREERUNNING_UMASK_START) >> 4) & 0xf); > +} Other than that this looks reasonable.