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 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
