For mobile devices and laptops, the ability to turn off ticks on certain cores translates to huge power savings. I almost doubled my battery life on a quad core laptop when I switched from a full-tick to a dynamic-tick kernel.

A single percent performance gain for all Linux using systems sounds massively worth it to me.

It's interesting, when you think about it from that perspective.

On my system, maybe that 1% improvement doesn't mean very much.

But when you add up all the systems in the world that are running Linux, and think about how much electricity is used by them or how many personal experiences they are mediating, it really adds up into something worthwhile.

The curious question is: at what point does it become not worthwhile? 1% is maybe worthwhile. But .01%? .5%?

> at what point does it become not worthwhile

There is always someone who will want to do it if only to show they can. You only need to care about "worthwhile" if you're balancing it against other concerns.

Obviously people are generally going to be motivated to smash the larger ones first. But Linux doesn't run like a centralized project where developers are directed on what to prioritize.

If you've got 100 CPU cores at or near full utilization, you've just saved yourself a CPU core. 100 machines at full utilization, it's a full machine.

The more cores/machines you have, the more this savings means. The threshold "is it worth it?" percentage depends on how many machines saved is worth an engineer's time to do the optimization.

Presumably users will gladly accept any positive % as long as it works, so the question comes down to what are the motivations of those actually implementing (or green-lighting) the commits.

I would say that so long as there are issues that have been identified to negatively affect performance, whichever issue has the biggest performance impact should always be considered worthwhile.

I was under the impression that tickless operation would translate to better power savings, but I may be wrong on this.

Precisely. The latency of some of the more aggressive power states exceeds the resolution of most OS tick timers, so they are often aborted for no good reason. So, as I'm typing this reply, in-between keystrokes, voltage to the CPU can be killed (not just clock-gated).

And it gets even better when you can postpone several low-priority interrupts for a while until a high-priority interrupt comes in, and then you wake up the CPU and handle them all at once before putting the CPU back to sleep.

Hmm. Completely brown-out the CPU in between keypresses? I always heard cold starts are very very slow (compared to regular operation). While I guess I don't have a measure for how slow, it seems unlikely that if a user is typing at 360CPM (60WPM * ~7), that you will be able to completely shut off the CPU much.

I'm not sure about the CPU numbers either (though my understanding is that modern CPUs are super-quick to power down and back up), but I think 360 CPM is way too high: few people type at 60 WPM, most words aren't 7 letters long, and nearly no one is typing 100% of the time they're at their computer.

Oh, I agree there is ample opportunity for shutting down the CPU. I probably spend more time just looking at the screen reading, than any other activity.

I know the Linux's default scheduler ticks are, depending on the platform, ~10 ms or less. How long are the latencies of the slower power state changes?

The tick is every 1 ms and C6 wakeup latency can be over 100 us, so ticks could suck over 10% of your performance (and plenty of energy).

Being tickless when idle provides significant power savings. Being tickless when active doesn't. The benefit here is to avoid trapping into the kernel an additional HZ times a second when you have a single CPU bound task bound to a CPU that nothing else wants to run on.