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
> 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?
> Himanshu Sharma
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.