* [Intel Alderlake CPUID issue] @ 2024-01-31 0:30 Tingrun Chen 2024-01-31 0:58 ` Ian Rogers 0 siblings, 1 reply; 4+ messages in thread From: Tingrun Chen @ 2024-01-31 0:30 UTC (permalink / raw) To: linux-perf-users; +Cc: Ian Rogers `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`. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Intel Alderlake CPUID issue] 2024-01-31 0:30 [Intel Alderlake CPUID issue] Tingrun Chen @ 2024-01-31 0:58 ` Ian Rogers 2024-01-31 15:01 ` Liang, Kan 0 siblings, 1 reply; 4+ messages in thread From: Ian Rogers @ 2024-01-31 0:58 UTC (permalink / raw) To: Tingrun Chen, Liang, Kan, Kan Liang; +Cc: linux-perf-users, 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Intel Alderlake CPUID issue] 2024-01-31 0:58 ` Ian Rogers @ 2024-01-31 15:01 ` Liang, Kan 2024-01-31 15:49 ` Ian Rogers 0 siblings, 1 reply; 4+ messages in thread From: Liang, Kan @ 2024-01-31 15:01 UTC (permalink / raw) To: Ian Rogers, Tingrun Chen, Kan Liang; +Cc: linux-perf-users, Ian Rogers 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Intel Alderlake CPUID issue] 2024-01-31 15:01 ` Liang, Kan @ 2024-01-31 15:49 ` Ian Rogers 0 siblings, 0 replies; 4+ messages in thread From: Ian Rogers @ 2024-01-31 15:49 UTC (permalink / raw) To: Liang, Kan, Wang, Weilin; +Cc: Tingrun Chen, Kan Liang, linux-perf-users 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-01-31 15:49 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-01-31 0:30 [Intel Alderlake CPUID issue] Tingrun Chen 2024-01-31 0:58 ` Ian Rogers 2024-01-31 15:01 ` Liang, Kan 2024-01-31 15:49 ` Ian Rogers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).