SOLUTION 已验证 - 已更新 2018年五月29日19:35 -
Red Hat Enterprise Linux 7
Reading /dev/cpu_dma_latency
from userspace / user mode is not clarified in kernel sources in 'Documentation/power/pm_qos_interface.txt'
reading /dev/cpu_dma_latency
prints gibberish
# cat /dev/cpu_dma_latency
�5w
Reading /dev/cpu_dma_latency
returns the raw value for the cpu QoS latency target in microseconds. Since this value is "raw" (not encoded as text) you can read it with something like hexdump. By default on Red Hat Enterprise Linux 7 it is set to 2000 seconds.
# hexdump -C `/dev/cpu_dma_latency`
00000000 00 94 35 77 |..5w|
00000004
# echo $(( 0x77359400 ))
2000000000
This is set in the kernel source code in 'include/linux/pm_qos.h'
#define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE (2000 * USEC_PER_SEC)
When some application such as for example 'tuned' with profile 'latency-performance' is running, then you will see a different value such as:
# hexdump -C `/dev/cpu_dma_latency`
00000000 01 00 00 00 |....|
00000004
The 'latency-performance' profile of tuned uses "force_latency=1" which writes '1' to /dev/cpu_dma_latency
. Zero would completely disable some power management frequency and voltage scaling depending on cpu hardware capabilities. A value of "1" is the lowest possible latency target before completely disabling some power management functionality.
For more details regarding latency requirements and power management please refer to:
Are hardware power management features causing latency spikes in my application?