[PATCH 00/17] coresight: next v4.12-rc4

Hi Kim,

On Thu, Jun 15, 2017 at 09:22:46AM -0500, Kim Phillips wrote:

On Thu, 15 Jun 2017 09:41:22 +0100
Sudeep Holla [off-list ref] wrote:

quoted

On 15/06/17 04:34, Kim Phillips wrote:
[...]

quoted

How does one tell whether writes to /dev/cpu_dma_latency are effective?

Watch /sys/devices/system/cpu/cpu*/cpuidle/state*/{usage,time}, they
shouldn't tick based on the value set to cpu_dma_latency.

E.g. a value of 0 should stop entering all the idle states.

I see all states following the same pattern whether 0 or not:

root at juno:~# cat show2.sh 
show()
{
	echo $1 > /dev/cpu_dma_latency
	echo === $1:
	cat /sys/devices/system/cpu/cpu2/cpuidle/state*/{usage,time}
	echo ---
	sleep 10
	cat /sys/devices/system/cpu/cpu2/cpuidle/state*/{usage,time}
}

show 0
show 1500
show 0
root at juno:~# taskset -c 2 bash ./show2.sh
=== 0:
1893
894
5417
1398675
65997648
3818880750
---
1895
905
5434
1401721
68076867
3826795502
=== 1500:
1895
905
5434
1401721
68076867
3826795502
---
1895
918
5447
1401721
69403510
3835466081
=== 0:
1895
918
5447
1401721
69403510
3835466081
---
1896
929
5463
1403577
71454839
3843409979

googling suggests the /dev/cpu_dma_latency file should be *kept* open,
and written a 32-bit binary number:

https://access.redhat.com/articles/65410

If so (I don't have time to test), this cpu debug documentation is very
deceptive.

Looked into the code, and I must apologize I have not verified the
command when wrote the doc. As you pointed out, the closing file
operation releases the constraint for PM QoS.

Below command can work (I tested):
exec 3<> /dev/cpu_dma_latency; echo 0 >&3

Will commit one patch for this.

Thanks,
Leo Yan