The state of the dynamic tick patch

[Posted August 31, 2005 by corbet]

The configurable timer interrupt frequency patch, part of the 2.6.13 kernel, led to a certain amount of controversy over the optimal default value. That default is 250 Hz, but there arguments in favor of both increasing and decreasing that value. There was no consensus on what the default should really be, but there is a certain amount of agreement that the real solution is to merge the dynamic tick patch. By varying the timer interrupt frequency in response to the actual system workload, the dynamic tick approach should be able to satisfy most users.

Now that patches are being merged for 2.6.14, the obvious question came up: will dynamic tick be one of them? The answer, it seems, is almost certainly "no." This patch, despite being around in one form or another for years, is still not quite ready.

One issue, apparently, is that systems running with dynamic tick tend to boot slowly, and nobody has yet figured out why. The problem can be masked by simply waiting until the system has booted before turning on dynamic tick, but that solution appeals to nobody. Until this behavior is understood, there will almost certainly be opposition to the merging of this patch.

Another problem with the current patch is that it does not work particularly well on SMP systems. It requires that all CPUs go idle before the timer interrupt frequency can be reduced. But an SMP system may well have individual CPUs with no work to do while others are busy; such a situation could come up fairly often. Srivatsa Vaddagiri is working on a patch for SMP systems, but it is still a work in progress and has not received widespread testing.

The end result is that dynamic tick is unlikely to come together in time to get into 2.6.14; the window for merging of patches of this magnitude is supposed to close within a week or so. So this patch will be for 2.6.15 at the earliest. If the revised development process works as planned, 2.6.15 should not be all that far away. Hopefully.

Index entries for this article
Kernel	Timer frequency

dynamic tick patch and slow boot

Posted Sep 2, 2005 3:29 UTC (Fri) by roelofs (guest, #2599) [Link] (2 responses)

One issue, apparently, is that systems running with dynamic tick tend to boot slowly, and nobody has yet figured out why.

I know the CELF group has done some detailed studies of boot time (an obvious point of interest for CE devices), and I thought LWN covered some more generic kernel boot-time studies--with graphs, even--a year or two back. Has anyone done something like that yet? More precisely, is the slowness evenly spread across all kernel subsystems, or is it confined only to those related to HW probing, or ...? That seems like an obvious first step to understanding the nature of the problem.

Greg

dynamic tick patch and slow boot

Posted Sep 8, 2005 23:35 UTC (Thu) by barrygould (guest, #4774) [Link] (1 responses)

I don't think this is about KERNEL boot timing, but here's some recent articles about Fedora boot times:

http://www.improvedsource.com/view.php/Linux-System/2/

http://www.improvedsource.com/view.php/Linux-System/3/

Also, I believe the articles on LWN in the past were not specifically about kernel boot times either, IIRC.

Barry

dynamic tick patch and slow boot

Posted Sep 9, 2005 3:56 UTC (Fri) by roelofs (guest, #2599) [Link]

Also, I believe the articles on LWN in the past were not specifically about kernel boot times either, IIRC.

Now that you mention it, I believe you're correct. Pity...

Ah, yes, here's the front-page article I was remembering: Fedora: an example of community involvement, which led to the Bootchart project. And a year earlier, there was this article: Boot Linux faster (IBM developerWorks). Nothing obvious for the kernel itself, though I'm almost certain the CELF folks did a fair bit of work on that.

Greg

The state of the dynamic tick patch

Posted Sep 5, 2005 6:39 UTC (Mon) by vatsa (guest, #13286) [Link]

I am afraid I dont see any slow bootup on x86. Maybe ARM/OMAP specific
or because of the fact that OMAP implementation was not using nohz_cpu_mask bitmap (which RCU cares about). The rework I did takes care of using
nohz_cpu_mask bitmap.

The state of the dynamic tick patch

Posted Sep 6, 2005 8:10 UTC (Tue) by tytso (subscriber, #9993) [Link]

The other outstanding problem is that the bus master activity business huerstics in ACPI is broken with the current dynamic tick patch; this means that laptops don't go into the lower power C states, and at least on my laptop (with an Pentium M chip) enabling dynamic tick causes the laptop to use more power (when in fact if done right it should actually save power).