What is the drawback for Skew_tick=1? Thanks

[DDPower]

Some literature recommends setting skew_tick=1 to optimize the delay problem；What is the drawback for Skew_tick=1? Why the kernel is 0 by default？Thanks

 

[Condobloke]

G'day DDPower, Welcome to Linux.org

Some detail may help

OS?...etc etc...

What you are trying to achieve......what you have already done?

etc

 

[xlbooyahlx]

Used to minimize latency in kernels
Here's a ton of stuff on it.

 

[osprey]

Some literature recommends setting skew_tick=1 to optimize the delay problem；What is the drawback for Skew_tick=1? Why the kernel is 0 by default？Thanks

The kernel parameter: skew_tick has the following indications in the kernel docs:

skew_tick=      [KNL] Offset the periodic timer tick per cpu to mitigate
                        xtime_lock contention on larger systems, and/or RCU lock
                        contention on all systems with CONFIG_MAXSMP set.
                        Format: { "0" | "1" }
                        0 -- disable. (may be 1 via CONFIG_CMDLINE="skew_tick=1"
                        1 -- enable.
                        Note: increases power consumption, thus should only be
                        enabled if running jitter sensitive (HPC/RT) workloads.

The parameter is used in case of jitter rather than a perceptible "delay problem", and since clock ticks tend to be up around 1000th of a second, "delay" is likely to be quite imperceptible. The price of using the parameter, as mentioned, is increased power consumption.

Jitter is about fluctuations in transmission signals, so that, for example in a network transmission it would refer to a bit arriving a little time before or after a clock cycle. Whether delay is perceptible on a desktop, is a moot point. AIUI the parameter is usually used on large work intensive machines.

 

[DDPower]

G'day DDPower, Welcome to Linux.org

Some detail may help

OS?...etc etc...

What you are trying to achieve......what you have already done?

etc

Thank you for your attention.
CentOS 8 on a 128 cores(ARM N2) processor system。When the OS starts, there is a voltage drop of 4mS period, which sometimes leads to a crash; increasing the core voltage or setting Skew_tick=1 can solve the problem。We want to know the possibly bad influence of setting Skew_tick=1?

 

[osprey]

Thank you for your attention.
CentOS 8 on a 128 cores(ARM N2) processor system。When the OS starts, there is a voltage drop of 4mS period, which sometimes leads to a crash; increasing the core voltage or setting Skew_tick=1 can solve the problem。We want to know the possibly bad influence of setting Skew_tick=1?

If the voltage drop is caused by jitter, there is a testing suite to measure jitter for which you can clone:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git

If the testing indicates an absence of jitter, then you may be able to discount its involvement in the voltage drop, and look beyond ticks. Overall perspective on ticks is here:

https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt

You probably need to check the kernel configuration which are controlling ticks such as:
CONFIG_NO_HZ_COMMON, CONFIG_NO_HZ_IDLE, CONFIG_NO_HZ_FULL, CONFIG_NO_HZ, CONFIG_HZ_PERIODIC, and some more mentioned in the link, to see what the kernel is doing with them. The linked article outlines the cost of various tick implementations.

 

[DDPower]

Thanks a lot.
But, why the kernel is 0 by default？
If it is set to 0 or 1, the impact on actual system operation is only power consumption？

 

[osprey]

Asking google's bard your question elicited the following answer for your info (which I think should be read in the context of the kernel docs already referred to):
"what is the drawback of using skew_tick=1 in linux?"

The only known drawback of using skew_tick=1 in Linux is that it could theoretically cause higher power consumption because a socket would take more time (or be unable) to shut itself down when idle. However, this hasn't been measured on recent kernels.

The skew_tick=1 parameter causes the kernel to program each CPU's tick timer to fire at different times, avoiding any possible lock contention. This can be beneficial for workloads that are sensitive to jitter, but it can also lead to higher power consumption.

In practice, the impact of skew_tick=1 on power consumption is likely to be small. However, if you are concerned about power consumption, you may want to avoid using this parameter.

Here are some additional details about the skew_tick=1 parameter:

It is only relevant when nohz_full is NOT used.
It does not hurt if used with nohz_full.
It has not been measured on recent kernels to see if it actually causes higher power consumption.

Overall, the drawback of using skew_tick=1 in Linux is that it could theoretically cause higher power consumption. However, this has not been measured on recent kernels, so it is likely to be a small impact. If you are concerned about power consumption, you may want to avoid using this parameter.

The reason the kernel skew_tick parameter value is zero by default is almost certainly not to incur the power consumption penalty, and leave it to system administrators to decide their own cases on their merits.

 

[DDPower]

Asking google's bard your question elicited the following answer for your info (which I think should be read in the context of the kernel docs already referred to):
"what is the drawback of using skew_tick=1 in linux?"

The reason the kernel skew_tick parameter value is zero by default is almost certainly not to incur the power consumption penalty, and leave it to system administrators to decide their own cases on their merits.

Thank you very much!