I'm not sure how much you know, so with the risk of explaining things you aready know: NO_HZ config options are there to remove ticks if theres nothing in the

I'm not sure how much you know, so with the risk of explaining things you aready know: NO_HZ config options are there to remove ticks if theres nothing in the process queue. This just means "Check if >1 processes need CPU time from the kernel, if not, skip"; The drawback is that it can actually be worse for latency, as you say, because there is an kernel<->userspace buffer that has to be checked and this is pure overhead. However, if your process is mostly userspace (and almost no kernel interaction) then you will see better performance, because your process won't have CPU stolen by the kernel if there's nothing to be processed. Since it doesn't remove ticks entirely, (just aborts ticks early); setting a high value for your tickrate gives you the best odds of getting your kernel bits rid of as soon as possible to minimise latency when there are ticks. I think they're trying to compromise betweeen having a low tickrate (so a process gets a lot of CPU time for each tick) and a high tickrate (so kernel calls don't take long before they see CPU time). I think the combination needs to be tested with your workflow, they conflict and might make things less good for many workloads (heavy IO, data processing, compiling)