cpuidle & ethernet performance

Hi Titus,

I've continued to investigate this.
I see that I get degregation when there is no activity in serial (from time of starting the test till finishing the test). I though That it means that omap3530 gets into retention in such scenario, but to my surprise the retention counter did not change during the test:

~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state4/time
70254200

~ # ./iperf -c 150.42.40.220 -w 2000
WARNING: TCP window size set to 2000 bytes. A small window size
will give poor performance. See the Iperf documentation.
------------------------------------------------------------
Client connecting to 150.42.40.220, TCP port 5001
TCP window size: 3.91 KByte (WARNING: requested 1.95 KByte)
------------------------------------------------------------
[ 5] local 150.42.40.221 port 49380 connected with 150.42.40.220 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 7.67 MBytes 6.43 Mbits/sec

~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state4/time
70254200


What can be the reason for this degredation.
When I set in code sleep_while_idle = 0.
I have no degredation (though there is no entering into retention at all). Is it that there is some failure in the counter progress that can explain this ?


Regards,
Ran

Ran,

There could be at least two different frameworks (cpufreq and cpuidle) affecting performance in your use case.

I would recommend disabling both and measuring performance to get a baseline and then enable one at the time and re-measure performance.

You can disable cpufreq by switching to userspace governor and setting desired MPU frequency under /sys/devices/system/cpu/cpu0/cpufreq/

You can disable cpuidle from config or from filesystem echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state<X>/disable

Good luck,

Carlos

Hi Carlos,

Thank you very much for your suggestions.
I've did several testing and I know the following:

1. It is cpuidle issue , not cpufreq that is responsible for the degredation
2. Using iperf test on terget I see that on large packet test (16k), I get same bandwidth (no degredation) in version with cpuidle support as in version without cpuidle supported.
3. But on doing same test with small packet test (<2000 bytes), I get high degredation in performance in version with cpuidle. On viewing statistics I see that the cpu gets (several times in and out state during test) into cpu inactive state (C3 state - not retention yet, only cpu not active). I guess this is the cause of the degredation. With large packets I get no increment in C3 state usage.

Does this behaviour make sense (why only small packets get into C3 state) ?

I think that menu governer behaviour might explain this, but I don't understand it deeply enough.
Maybe if I can enlarge the timeout in menu governer from non idle to entering idle state , it might resolve this issue ?

Regards,
Ran

Hi Carlos,

Is there a way to overcome this behaviour, so that mpu will "think" that there is not enough time for entering idle mode ? Maybe by changing a parameter in governer ? The thing is that we still want to use cpuidle, yet without degredation in performace.

Thanks,
Ran