How to get CPU clock frequency on an ARM/Linux machine - linux

The answer seems pretty obvious I guess but none of the possible answers given in https://superuser.com/questions/406141/how-to-get-an-arm-cpu-clock-speed-in-linux applies to me.
cat /proc/cpuinfo
only gives me
processor : 0
model name : ARMv7 Processor rev 2 (v7l)
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2
Hardware : Generic AM33XX (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000
and there is no file called cpuinfo_*_freq below /sys/devices/system/cpu.
I don't have hwinfo or dmidecode or any executable called cpu* on this machine :)
Do you know how to retrieve or 'measure' a CPU's actual frequency programatically?

you could try dmidecode|grep MHz

Related

Unable to Write in MSR_EBC_FREQUENCY_ID (0x2C) on Pentium 4 Processor

I want to modify "Core Clock Frequency to System Bus Frequency Ratio BITS[31:24]" in register MSR_EBC_FREQUENCY_ID (0x2C) on Pentium 4 desktop processor by developing a Linux Kernel Module (LKM/Driver). Below the processor details.
Name: Intel(R) Pentium(R) 4,
Type: 0,
Family: 15 (0xF),
Model: 2,
Stepping: 7
Ref: https://software.intel.com/sites/default/files/managed/22/0d/335592-sdm-vol-4.pdf (Page-316, Table 2-44).
But the write call (wrmsr) unable to write the desired value in the register!!!
Please let me know how can I write on this MSR? Do I need to do other things to write on this register?
Thanks in advance.
These bits are read-only according to Intel SDM:
31:24 Core Clock Frequency to System Bus Frequency Ratio (R)

Cross compiler for MIPS doesn't seem to create valid programs

I've set up a cross compiler using buildroot.
The target device is running Linux and it has a MIPS processor (it's a Dreambox dm500hd).
Buildroot configuration (only the things that I've changed):
Target configuration
Architecture: MIPS (little endian)
Architecture variant: Generic MIPS32
Toolchain configuration
[*] Enable C++ Support
[*] Enable compiler link-time-optimization support
I've followed the setup procedure and buildroot makes the compiler successfully (mips-linux-gcc and g++).
Hello World file (test-mips.cpp)
#include <iostream>
using namespace std;
int main() {
cout << "hello world";
return 0;
}
I can compile Hello World, but when I run it on the target device an error is thrown:
dm500hd:~$ ./test-mips
./test-mips: line 1: EL#4▒�P4: not found
./test-mips: line 1: syntax error: unexpected word (expecting ")")
The strange characters appear only if I build the compiler for little-endian: the error for programs compiled with big-endian is the same, but with spaces instead of ▒�.
I tried both little endian and big endian but the problem is the same. Have I done something wrong while configuring buildroot then?
Note: cat /proc/cpuinfo game me this result. Should I change the Architecture Variant?
system type : BCM7413B1 STB platform
processor : 0
cpu model : Brcm4380 V4.4 FPU V0.1
BogoMIPS : 403.45
cpu MHz : 405.010
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : no
ASEs implemented : mips16
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
processor : 1
cpu model : Brcm4380 V4.4 FPU V0.1
BogoMIPS : 403.45
cpu MHz : 405.010
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : no
ASEs implemented : mips16
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
Do you run on your target system the root filesystem generated by Buildroot ? Or do you just built your program with the Buildroot toolchain, and moved it to your existing filesystem on the target ?
In the latter case, then don't expect that to work out of the box. You have to make sure your program is ABI compatible with the reset of the system that already exists on your target system.

Why does `change_protection` hog CPU while loading a large amount of data into RAM?

We have built an in-memory database, which eats about 100-150G RAM in a single Vec, which is populated like this:
let mut result = Vec::with_capacity(a_very_large_number);
while let Ok(n) = reader.read(&mut buffer) {
result.push(...);
}
perf top shows that the time is mostly spent in this "change_protection" function:
Samples: 48K of event 'cpu-clock', Event count (approx.): 694742858
62.45% [kernel] [k] change_protection
18.18% iron [.] database::Database::init::h63748
7.45% [kernel] [k] vm_normal_page
4.88% libc-2.17.so [.] __memcpy_ssse3_back
0.92% [kernel] [k] copy_user_enhanced_fast_string
0.52% iron [.] memcpy#plt
The CPU usage of this function grows as more and more data is loaded into RAM:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12383 iron 20 0 137g 91g 1372 D 76.1 37.9 27:37.00 iron
The code is running on an r3.8xlarge AWS EC2 instance, and transparent hugepage is already disabled.
[~]$ cat /sys/kernel/mm/transparent_hugepage/defrag
always madvise [never]
[~]$ cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]
cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2670 v2 # 2.50GHz
stepping : 4
microcode : 0x428
cpu MHz : 2500.070
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 0
cpu cores : 8
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5000.14
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
kernel
3.14.35-28.38.amzn1.x86_64
The real question is why is there so much overhead in that function?
This seems to be an OS issue, rather than an issue with this specific rust function.
Most OSes (including Linux) use demand paging. By default, Linux will not allocate physical pages for newly allocated memory. Instead it will allocate a single zero page with read-only permissions for all the allocated memory (i.e., all virtual memory pages will point to this single physical memory page).
If you attempt to write to the memory, a page fault will happen, a new page will be allocated, and it's permissions will be set accordingly.
I'm guessing that you are seeing this effect in your program. If you try to do the same thing a second time, it should be much faster. There are also ways to control this policy via sysctl: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting.
Not sure why you disabled THP, but in this case large pages might help you since the protection change will happen once for every large page (2Mib) instead of once per normal page (4KiB).

What is my CPU speed?

I need the CPU speed of my KVM host.
When I am using dmidecode, the result is the following :
sudo dmidecode | egrep "Max Speed|Current Speed"
Max Speed: 3100 MHz
Current Speed: 3100 MHz
Whereas, when I am using lscpu, the result is:
lscpu | grep "MHz".
CPU MHz: 1600.000
So, why there are two different values, and between the two, which is my actual CPU speed?
Additional :
When the /proc/cpuinfo file has the following result for the speed of the individual cores.
cat /proc/cpuinfo | grep "MHz"
cpu MHz : 1600.000
cpu MHz : 1600.000
cpu MHz : 1600.000
cpu MHz : 1600.000
Can anybody explain in details?
Your CPU has a rated speed of 3.1GHz. At the time you checked cpuinfo, it was running at 1.6GHz. When load is low, the CPU runs at a lower speed to save energy and keep itself cooler.
If you have cpufreq running, the driver which reduces CPU frequency during inactivity periods, you may take maximum frequency from it (in KHz):
$ cd /sys/devices/system/cpu/cpu1/
$ sudo cat cpufreq/cpuinfo_cur_freq
2363000
$ cat cpufreq/cpuinfo_max_freq
2600000
Note that 2,6 GHz is Intel "Turbo" frequency of my CPU, actual stock frequency is 1,7 MHz.

Smaller model number and larger stepping value mean newer CPU version in /proc/cpuinfo in Linux?

I am checking the CPU information on two Linux VMs, on one VM, I see:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Xeon(R) CPU E5-2680 0 # 2.70GHz
stepping : 1
cpu MHz : 2699.999
cache size : 20480 KB
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
On another one, I see:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU E5-2680 0 # 2.70GHz
stepping : 4
cpu MHz : 2700.000
cache size : 20480 KB
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
May I ask if smaller model number and larger stepping value mean newer CPU version?
Model is the model number of the CPU.
Stepping is the incremental version number of the CPU.

Resources