[Intel Alderlake CPUID issue]

[Intel Alderlake CPUID issue]

[Tingrun Chen]

`perf test 7` fail on Alderlake virtual machine, The test is failing
as #system_tsc_freq has a zero value.Below is the output of `./perf
test 7 -vv`:
```
Couldn't bump rlimit(MEMLOCK), failures may take place when creating
BPF maps, etc
  7: Simple expression parser                                        :
--- start ---
test child forked, pid 82095
Using CPUID GenuineIntel-6-BA-2
parsing metric: 1+1
parsing metric: FOO+BAR
lookup(FOO): val 1.000000
lookup(BAR): val 2.000000
parsing metric: (BAR/2)%2
lookup(BAR): val 2.000000
parsing metric: 1 - -4
parsing metric: (FOO-1)*2 + (BAR/2)%2 - -4
lookup(FOO): val 1.000000
lookup(BAR): val 2.000000
parsing metric: 1-1 | 1
parsing metric: 1-1 & 1
parsing metric: min(1,2) + 1
parsing metric: max(1,2) + 1
parsing metric: 1+1 if 3*4 else 0
parsing metric: 100 if 1 else 200 if 1 else 300
parsing metric: 100 if 0 else 200 if 1 else 300
parsing metric: 100 if 1 else 200 if 0 else 300
parsing metric: 100 if 0 else 200 if 0 else 300
parsing metric: 1.1 + 2.1
parsing metric: .1 + 2.
parsing metric: d_ratio(1, 2)
parsing metric: d_ratio(2.5, 0)
parsing metric: 1.1 < 2.2
parsing metric: 2.2 > 1.1
parsing metric: 1.1 < 1.1
parsing metric: 2.2 > 2.2
parsing metric: 2.2 < 1.1
parsing metric: 1.1 > 2.2
parsing metric: 1.1e10 < 1.1e100
parsing metric: 1.1e2 > 1.1e-2
parsing metric: FOO/0
lookup(FOO): val 1.000000
division by zero
parsing metric: BAR/
lookup(BAR): val 2.000000
syntax error
parsing metric: FOO + BAR + BAZ + BOZO
parsing metric: EVENT1\,param\=?@ + EVENT2\,param\=?@
parsing metric: dash\-event1 - dash\-event2
parsing metric: EVENT1 if #smt_on else EVENT2
literal: #smt_on = 0.000000
parsing metric: EVENT1 if #core_wide else EVENT2
literal: #core_wide = 0.000000
parsing metric: 1.0 if EVENT1 > 100.0 else 1.0
parsing metric: 0 & EVENT1 > 0
parsing metric: EVENT1 > 0 & 0
parsing metric: 1 & EVENT1 > 0
parsing metric: EVENT1 > 0 & 1
parsing metric: 1 | EVENT1 > 0
parsing metric: EVENT1 > 0 | 1
parsing metric: 0 | EVENT1 > 0
parsing metric: EVENT1 > 0 | 0
parsing metric: #num_cpus_online
literal: #num_cpus_online = 8.000000
parsing metric: #num_cpus
literal: #num_cpus = 8.000000
parsing metric: #num_cores
literal: #num_cores = 8.000000
parsing metric: #num_dies
literal: #num_dies = 1.000000
parsing metric: #num_packages
literal: #num_packages = 1.000000
parsing metric: #system_tsc_freq
Failed to find TSC frequency in /proc/cpuinfoliteral: #system_tsc_freq
= 0.000000
FAILED tests/expr.c:249 #system_tsc_freq > 0
test child finished with -1
---- end ----
Simple expression parser: FAILED!
```
The test can pass in my AlderLakephysical machine. So, in my physical
machine it seems that in the `arch_get_tsc_freq`
(https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/arch/x86/util/tsc.c?h=perf-tools-next)
function, the call to `get_cpuid_0` will read a valid value for lvl,
then it will calculate the tsc using the information directly from the
intel instruction `cpuid`; however, in the virtual machine, the lvl
will be less than 0x15, then it will fall back to read `/proc/cpuinfo`
and it does not contain something like `@ 3.0GHz`. Interestingly, the
`model name` entry of `/proc/cpuinfo` in both my physical machine and
the virtual machine does not contain the frequency information like `@
3.0GHz`.

Re: [Intel Alderlake CPUID issue]

[Ian Rogers]

On Tue, Jan 30, 2024 at 4:35 PM Tingrun Chen <tchen168@asu.edu> wrote:
>
> `perf test 7` fail on Alderlake virtual machine, The test is failing
> as #system_tsc_freq has a zero value.Below is the output of `./perf
> test 7 -vv`:
> ```
> Couldn't bump rlimit(MEMLOCK), failures may take place when creating
> BPF maps, etc
>   7: Simple expression parser                                        :
> --- start ---
> test child forked, pid 82095
> Using CPUID GenuineIntel-6-BA-2
> parsing metric: 1+1
> parsing metric: FOO+BAR
> lookup(FOO): val 1.000000
> lookup(BAR): val 2.000000
> parsing metric: (BAR/2)%2
> lookup(BAR): val 2.000000
> parsing metric: 1 - -4
> parsing metric: (FOO-1)*2 + (BAR/2)%2 - -4
> lookup(FOO): val 1.000000
> lookup(BAR): val 2.000000
> parsing metric: 1-1 | 1
> parsing metric: 1-1 & 1
> parsing metric: min(1,2) + 1
> parsing metric: max(1,2) + 1
> parsing metric: 1+1 if 3*4 else 0
> parsing metric: 100 if 1 else 200 if 1 else 300
> parsing metric: 100 if 0 else 200 if 1 else 300
> parsing metric: 100 if 1 else 200 if 0 else 300
> parsing metric: 100 if 0 else 200 if 0 else 300
> parsing metric: 1.1 + 2.1
> parsing metric: .1 + 2.
> parsing metric: d_ratio(1, 2)
> parsing metric: d_ratio(2.5, 0)
> parsing metric: 1.1 < 2.2
> parsing metric: 2.2 > 1.1
> parsing metric: 1.1 < 1.1
> parsing metric: 2.2 > 2.2
> parsing metric: 2.2 < 1.1
> parsing metric: 1.1 > 2.2
> parsing metric: 1.1e10 < 1.1e100
> parsing metric: 1.1e2 > 1.1e-2
> parsing metric: FOO/0
> lookup(FOO): val 1.000000
> division by zero
> parsing metric: BAR/
> lookup(BAR): val 2.000000
> syntax error
> parsing metric: FOO + BAR + BAZ + BOZO
> parsing metric: EVENT1\,param\=?@ + EVENT2\,param\=?@
> parsing metric: dash\-event1 - dash\-event2
> parsing metric: EVENT1 if #smt_on else EVENT2
> literal: #smt_on = 0.000000
> parsing metric: EVENT1 if #core_wide else EVENT2
> literal: #core_wide = 0.000000
> parsing metric: 1.0 if EVENT1 > 100.0 else 1.0
> parsing metric: 0 & EVENT1 > 0
> parsing metric: EVENT1 > 0 & 0
> parsing metric: 1 & EVENT1 > 0
> parsing metric: EVENT1 > 0 & 1
> parsing metric: 1 | EVENT1 > 0
> parsing metric: EVENT1 > 0 | 1
> parsing metric: 0 | EVENT1 > 0
> parsing metric: EVENT1 > 0 | 0
> parsing metric: #num_cpus_online
> literal: #num_cpus_online = 8.000000
> parsing metric: #num_cpus
> literal: #num_cpus = 8.000000
> parsing metric: #num_cores
> literal: #num_cores = 8.000000
> parsing metric: #num_dies
> literal: #num_dies = 1.000000
> parsing metric: #num_packages
> literal: #num_packages = 1.000000
> parsing metric: #system_tsc_freq
> Failed to find TSC frequency in /proc/cpuinfoliteral: #system_tsc_freq
> = 0.000000
> FAILED tests/expr.c:249 #system_tsc_freq > 0
> test child finished with -1
> ---- end ----
> Simple expression parser: FAILED!
> ```
> The test can pass in my AlderLakephysical machine. So, in my physical
> machine it seems that in the `arch_get_tsc_freq`
> (https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/arch/x86/util/tsc.c?h=perf-tools-next)
> function, the call to `get_cpuid_0` will read a valid value for lvl,
> then it will calculate the tsc using the information directly from the
> intel instruction `cpuid`; however, in the virtual machine, the lvl
> will be less than 0x15, then it will fall back to read `/proc/cpuinfo`
> and it does not contain something like `@ 3.0GHz`. Interestingly, the
> `model name` entry of `/proc/cpuinfo` in both my physical machine and
> the virtual machine does not contain the frequency information like `@
> 3.0GHz`.

+Kan Liang

Thanks Tingrun,

IIRC the "@ 3.0GHz" parsing approach was for older machines that
lacked the information in the cpuid. Could there be anything special
in your virtual machine set up that will cause the cpuid to look older
than it is? Kan, any thoughts and can we work around this?

Thanks,
Ian

Re: [Intel Alderlake CPUID issue]

[Liang, Kan]

On 2024-01-30 7:58 p.m., Ian Rogers wrote:
> On Tue, Jan 30, 2024 at 4:35 PM Tingrun Chen <tchen168@asu.edu> wrote:
>>
>> `perf test 7` fail on Alderlake virtual machine, The test is failing
>> as #system_tsc_freq has a zero value.Below is the output of `./perf
>> test 7 -vv`:
>> ```
>> Couldn't bump rlimit(MEMLOCK), failures may take place when creating
>> BPF maps, etc
>>   7: Simple expression parser                                        :
>> --- start ---
>> test child forked, pid 82095
>> Using CPUID GenuineIntel-6-BA-2
>> parsing metric: 1+1
>> parsing metric: FOO+BAR
>> lookup(FOO): val 1.000000
>> lookup(BAR): val 2.000000
>> parsing metric: (BAR/2)%2
>> lookup(BAR): val 2.000000
>> parsing metric: 1 - -4
>> parsing metric: (FOO-1)*2 + (BAR/2)%2 - -4
>> lookup(FOO): val 1.000000
>> lookup(BAR): val 2.000000
>> parsing metric: 1-1 | 1
>> parsing metric: 1-1 & 1
>> parsing metric: min(1,2) + 1
>> parsing metric: max(1,2) + 1
>> parsing metric: 1+1 if 3*4 else 0
>> parsing metric: 100 if 1 else 200 if 1 else 300
>> parsing metric: 100 if 0 else 200 if 1 else 300
>> parsing metric: 100 if 1 else 200 if 0 else 300
>> parsing metric: 100 if 0 else 200 if 0 else 300
>> parsing metric: 1.1 + 2.1
>> parsing metric: .1 + 2.
>> parsing metric: d_ratio(1, 2)
>> parsing metric: d_ratio(2.5, 0)
>> parsing metric: 1.1 < 2.2
>> parsing metric: 2.2 > 1.1
>> parsing metric: 1.1 < 1.1
>> parsing metric: 2.2 > 2.2
>> parsing metric: 2.2 < 1.1
>> parsing metric: 1.1 > 2.2
>> parsing metric: 1.1e10 < 1.1e100
>> parsing metric: 1.1e2 > 1.1e-2
>> parsing metric: FOO/0
>> lookup(FOO): val 1.000000
>> division by zero
>> parsing metric: BAR/
>> lookup(BAR): val 2.000000
>> syntax error
>> parsing metric: FOO + BAR + BAZ + BOZO
>> parsing metric: EVENT1\,param\=?@ + EVENT2\,param\=?@
>> parsing metric: dash\-event1 - dash\-event2
>> parsing metric: EVENT1 if #smt_on else EVENT2
>> literal: #smt_on = 0.000000
>> parsing metric: EVENT1 if #core_wide else EVENT2
>> literal: #core_wide = 0.000000
>> parsing metric: 1.0 if EVENT1 > 100.0 else 1.0
>> parsing metric: 0 & EVENT1 > 0
>> parsing metric: EVENT1 > 0 & 0
>> parsing metric: 1 & EVENT1 > 0
>> parsing metric: EVENT1 > 0 & 1
>> parsing metric: 1 | EVENT1 > 0
>> parsing metric: EVENT1 > 0 | 1
>> parsing metric: 0 | EVENT1 > 0
>> parsing metric: EVENT1 > 0 | 0
>> parsing metric: #num_cpus_online
>> literal: #num_cpus_online = 8.000000
>> parsing metric: #num_cpus
>> literal: #num_cpus = 8.000000
>> parsing metric: #num_cores
>> literal: #num_cores = 8.000000
>> parsing metric: #num_dies
>> literal: #num_dies = 1.000000
>> parsing metric: #num_packages
>> literal: #num_packages = 1.000000
>> parsing metric: #system_tsc_freq
>> Failed to find TSC frequency in /proc/cpuinfoliteral: #system_tsc_freq
>> = 0.000000
>> FAILED tests/expr.c:249 #system_tsc_freq > 0
>> test child finished with -1
>> ---- end ----
>> Simple expression parser: FAILED!
>> ```
>> The test can pass in my AlderLakephysical machine. So, in my physical
>> machine it seems that in the `arch_get_tsc_freq`
>> (https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/arch/x86/util/tsc.c?h=perf-tools-next)
>> function, the call to `get_cpuid_0` will read a valid value for lvl,
>> then it will calculate the tsc using the information directly from the
>> intel instruction `cpuid`; however, in the virtual machine, the lvl
>> will be less than 0x15, then it will fall back to read `/proc/cpuinfo`
>> and it does not contain something like `@ 3.0GHz`. Interestingly, the
>> `model name` entry of `/proc/cpuinfo` in both my physical machine and
>> the virtual machine does not contain the frequency information like `@
>> 3.0GHz`.
> 
> +Kan Liang
> 
> Thanks Tingrun,
> 
> IIRC the "@ 3.0GHz" parsing approach was for older machines that
> lacked the information in the cpuid. Could there be anything special
> in your virtual machine set up that will cause the cpuid to look older
> than it is? Kan, any thoughts and can we work around this?
> 

I don't have other way to get an accurate frequency.

Do you think it is worth introducing a way (e.g. terms) to let the end
user provide such information?
For this case, the freq information is not available.
In Weilin's TPEBS support, I think she is also looking for a way to set
the period.

Thanks,
Kan

Re: [Intel Alderlake CPUID issue]

[Ian Rogers]

On Wed, Jan 31, 2024 at 7:01 AM Liang, Kan <kan.liang@linux.intel.com> wrote:
>
>
>
> On 2024-01-30 7:58 p.m., Ian Rogers wrote:
> > On Tue, Jan 30, 2024 at 4:35 PM Tingrun Chen <tchen168@asu.edu> wrote:
> >>
> >> `perf test 7` fail on Alderlake virtual machine, The test is failing
> >> as #system_tsc_freq has a zero value.Below is the output of `./perf
> >> test 7 -vv`:
> >> ```
> >> Couldn't bump rlimit(MEMLOCK), failures may take place when creating
> >> BPF maps, etc
> >>   7: Simple expression parser                                        :
> >> --- start ---
> >> test child forked, pid 82095
> >> Using CPUID GenuineIntel-6-BA-2
> >> parsing metric: 1+1
> >> parsing metric: FOO+BAR
> >> lookup(FOO): val 1.000000
> >> lookup(BAR): val 2.000000
> >> parsing metric: (BAR/2)%2
> >> lookup(BAR): val 2.000000
> >> parsing metric: 1 - -4
> >> parsing metric: (FOO-1)*2 + (BAR/2)%2 - -4
> >> lookup(FOO): val 1.000000
> >> lookup(BAR): val 2.000000
> >> parsing metric: 1-1 | 1
> >> parsing metric: 1-1 & 1
> >> parsing metric: min(1,2) + 1
> >> parsing metric: max(1,2) + 1
> >> parsing metric: 1+1 if 3*4 else 0
> >> parsing metric: 100 if 1 else 200 if 1 else 300
> >> parsing metric: 100 if 0 else 200 if 1 else 300
> >> parsing metric: 100 if 1 else 200 if 0 else 300
> >> parsing metric: 100 if 0 else 200 if 0 else 300
> >> parsing metric: 1.1 + 2.1
> >> parsing metric: .1 + 2.
> >> parsing metric: d_ratio(1, 2)
> >> parsing metric: d_ratio(2.5, 0)
> >> parsing metric: 1.1 < 2.2
> >> parsing metric: 2.2 > 1.1
> >> parsing metric: 1.1 < 1.1
> >> parsing metric: 2.2 > 2.2
> >> parsing metric: 2.2 < 1.1
> >> parsing metric: 1.1 > 2.2
> >> parsing metric: 1.1e10 < 1.1e100
> >> parsing metric: 1.1e2 > 1.1e-2
> >> parsing metric: FOO/0
> >> lookup(FOO): val 1.000000
> >> division by zero
> >> parsing metric: BAR/
> >> lookup(BAR): val 2.000000
> >> syntax error
> >> parsing metric: FOO + BAR + BAZ + BOZO
> >> parsing metric: EVENT1\,param\=?@ + EVENT2\,param\=?@
> >> parsing metric: dash\-event1 - dash\-event2
> >> parsing metric: EVENT1 if #smt_on else EVENT2
> >> literal: #smt_on = 0.000000
> >> parsing metric: EVENT1 if #core_wide else EVENT2
> >> literal: #core_wide = 0.000000
> >> parsing metric: 1.0 if EVENT1 > 100.0 else 1.0
> >> parsing metric: 0 & EVENT1 > 0
> >> parsing metric: EVENT1 > 0 & 0
> >> parsing metric: 1 & EVENT1 > 0
> >> parsing metric: EVENT1 > 0 & 1
> >> parsing metric: 1 | EVENT1 > 0
> >> parsing metric: EVENT1 > 0 | 1
> >> parsing metric: 0 | EVENT1 > 0
> >> parsing metric: EVENT1 > 0 | 0
> >> parsing metric: #num_cpus_online
> >> literal: #num_cpus_online = 8.000000
> >> parsing metric: #num_cpus
> >> literal: #num_cpus = 8.000000
> >> parsing metric: #num_cores
> >> literal: #num_cores = 8.000000
> >> parsing metric: #num_dies
> >> literal: #num_dies = 1.000000
> >> parsing metric: #num_packages
> >> literal: #num_packages = 1.000000
> >> parsing metric: #system_tsc_freq
> >> Failed to find TSC frequency in /proc/cpuinfoliteral: #system_tsc_freq
> >> = 0.000000
> >> FAILED tests/expr.c:249 #system_tsc_freq > 0
> >> test child finished with -1
> >> ---- end ----
> >> Simple expression parser: FAILED!
> >> ```
> >> The test can pass in my AlderLakephysical machine. So, in my physical
> >> machine it seems that in the `arch_get_tsc_freq`
> >> (https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/arch/x86/util/tsc.c?h=perf-tools-next)
> >> function, the call to `get_cpuid_0` will read a valid value for lvl,
> >> then it will calculate the tsc using the information directly from the
> >> intel instruction `cpuid`; however, in the virtual machine, the lvl
> >> will be less than 0x15, then it will fall back to read `/proc/cpuinfo`
> >> and it does not contain something like `@ 3.0GHz`. Interestingly, the
> >> `model name` entry of `/proc/cpuinfo` in both my physical machine and
> >> the virtual machine does not contain the frequency information like `@
> >> 3.0GHz`.
> >
> > +Kan Liang
> >
> > Thanks Tingrun,
> >
> > IIRC the "@ 3.0GHz" parsing approach was for older machines that
> > lacked the information in the cpuid. Could there be anything special
> > in your virtual machine set up that will cause the cpuid to look older
> > than it is? Kan, any thoughts and can we work around this?
> >
>
> I don't have other way to get an accurate frequency.
>
> Do you think it is worth introducing a way (e.g. terms) to let the end
> user provide such information?
> For this case, the freq information is not available.
> In Weilin's TPEBS support, I think she is also looking for a way to set
> the period.

+Wang, Weilin

I think a term for an event or metric would be a bit unnatural, this
feels like a command line and/or config setting thing. I can draft a
patch.

Thanks,
Ian

> Thanks,
> Kan