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.


On Thursday, May 25, 2017 at 6:32:57 AM UTC-4, Himanshu Sharma wrote:
> 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

You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to