processor.max_cstate, intel_idle.max_cstate and /dev/cpu_dma_latency

[Himanshu Sharma]

Hi guys

Recently I have been playing around with redhat kernel (Red Hat Enterprise Linux Server release 7.2 (Maipo)) params a bit to look out for kernel level optimisations. One such optimisation is not allowing processes to go into C state which can be done by grub boot params intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll OR  /usr/libexec/tuned/pmqos-static.py cpu_dma_latency=0. I am a bit confused as to which one to use and what to expect.

I read this wonderful blog post http://www.breakage.org/2012/11/14/processor-max_cstate-intel_idle-max_cstate-and-devcpu_dma_latency/. Here Jeremy has mentioned in Test #6 that with /dev/cpu_dma_latency=0 and intel_idle.max_cstate=0, cmdline overrides /dev/cpu_dma_latency and cpu will be in c1 state for 99.99% of the time. However, when I recreated this on my server I am seeing the  cpus in c0 (Busy state) 100% of the time.

I am a bit confused as to why I am getting different results. What would be the preferrable way to keep cores in c0 (Busy state) 100% of the time using minimal kernel tweaking?

Thanks

Himanshu Sharma

[Sarunas Vancevicius]

idle=poll will force c0 state, removing that would lock in to c1.

[Peter Booth]

Himanshu,

The big opportunity here is to not set anything on the bootline and instead write to /dev/cpu_dma_latency.

Because this doesn't require a reboot it means that in, for example, a trading environment, we could run hosts 

with a latency sensitive configuration between 8am and 5pm, and then shift to a power-saving 

configuration after 5pm. That could make an enormous difference to data center power usage.

Peter