I mentioned recently that I downloaded about half a dozen kernel SMP .config files, and found that none of them had "tickless" enabled. Today I did a search for "config_nohz" (UPDATE: that should have been 'CONFIG_NO_HZ') and found this:

June 27, 2007:

Dave mentioned that Fedora Core 7 32-bit is now shipping with

CONFIG_NOHZ is known to break suspend and resume on some machines. These
problems are being fixed over time, but that's a risky decision for a
distribution to switch it on by default.

The kernel is out, and reading the changelog there are important bugfixes. A couple are to do with hanging at bootup, another is to do with a bug in "jiffies" -- which I know nothing about but I do know that it is a key part of some modem drivers such as ltserial.

So, today I will go through the entire exercise again, all the 3rd party drivers also, this time with tickless disabled. I might bring out just the one kernel this time, for alpha7.

Posted on 25 Aug 2008, 8:26


Posted on 25 Aug 2008, 8:56 by BarryK
I just discovered that the kernel accepts the boot parameter 'nohz=off' if we want to turn it off.

Posted on 25 Aug 2008, 8:22 by BarryK
Re: tickless roubles
I have seen some recommendations on the web to do this"
nohz=off highres=off

Some interesting quotes:

Kernel runs cooler on this machine, even when booted "nohz=off", than
Kernel 2.6.25.* in tickless mode. The difference, in both coretemp and ACPI
thermal zone, is typically 4-6 C.

The kernel's tickless mode is enabled by default in Fedora 7 and 8, but can sometimes cause incorrect timekeeping. Using nohz=off highres=off will disable it.

I'm running openSUSE 10.3 ( and when I recently upgraded to 1.5.4, I noticed _after_ the first boot, my VM consumes 50-75% of System time. If I pass `nohz=off' to the kernel, the problem goes way (usage down to 5-6%).

A short summary what has been found out that far:
- apic timer breaks on C2 or deeper
- noapictimer workaround helps to come a bit further, but results in sever
other errors (see comment #13)
- "nohz=off highres=off" works (tested on and SUSE kernels)
- processor.max_cstate=1 works
- This affects AMD Mobile Semprons (at least 3500+ and 3600+)

nohz=off seems to do the trick- have been using the virtual machine for a couple of hours with both CPU's enabled without hanging.

The problem seems to be the AMD ATI SB600 chipset support in Linux. After
following and participating in intensive discussions in the internet it seems
that all PCs with this chipset will need "nohz=off" for booting (or much more
limiting "safe settings").

...and so it goes on. Many of these comments are quite recent. I think that I will follow Slackware 12.1 and disable tickless and hi-res timer. This is the config for the Slackware kernel:

# CONFIG_NO_HZ is not set

Posted on 25 Aug 2008, 8:28 by tempestuous
If you configure this kernel with SMP enabled, please also enable HyperThreading and Multicore, since these are really just variations of SMP.
And I think that there will be more users with multicore and hyperthreading processors out there than there will be with true multiple processors.

Posted on 25 Aug 2008, 9:51 by BarryK
Re: SMP config
Referring to the Slackware config:

# CONFIG_PREEMPT is not set

...I guess I'll copy Slackware. I do note one difference from Puppy, we have voluntary preeemption I think ...not sure whther to follow Slackware on that one.

Posted on 25 Aug 2008, 9:54 by BarryK
Re: HT
Oh yeah, Slackware has this too:

Posted on 25 Aug 2008, 10:53 by tempestuous
CONFIG_SCHED_SMT is for hyperthreading.

CONFIG_X86_HT is confusing. It was a legacy setting in older kernels, but now apparently affects Opteron 64bit support. Since Puppy is 32bit we could assume it is of no use.

Posted on 25 Aug 2008, 15:28 by Veronicathecow
Dual config on boot
Is it possible to have the ISO with an extra safe boot entry as standard.

Then when using the Puppy Universal Installer perhaps add a small set of tick boxes for the various options (Tickless etc and maybe loglevel?) which would change the Grub written to the HDDs?
Please excuse if this is a bit simplistic. Tony

Posted on 25 Aug 2008, 23:53 by Dougal
SMP vs. tickless
I think it makes more sense to give up SMP in favor of a tickless kernel...

The percentage of machines Puppy is used on which are multi-core/cpu is probably not so big and, quite frankly, I don't think it is that critical:
It's not like the average Puppy user spends all day running mksquashfs or such cpu-intensive applications that will benefit greatly from SMP. It is more likely that all these machines spend most of their time idling, in which case the power saving from running a tickless kernel would probably be welcome (I may be mistaken, but that's how it seems to me).

Posted on 25 Aug 2008, 24:14 by Aitch
Having only just had SCSI booting published by SHS which now enables me to use [I think as I haven't completed this bit yet] my Dell twin P3/1.2Ghz processor server mobo, please don't now sabotage it, as Dougal seems to be suggesting. Not all of us can afford nice 3.6ghz++ multicores!
Keep twin processor support. Puppy earned it's name reviving older hardware, don't abandon it now
Pleeeeez - ta muchly!! :)
Good work, Barry, keep it up!

Posted on 26 Aug 2008, 6:08 by Scott
Prefer SMP to Tickless
From the investigation Barry has done, it seems like "tickless" is not yet ready for prime time, and that any power savings are very dependent on the specific hardware configuration and intended application. With even the low-end Atom processors being multi-core, and older Pentium CPUs supporting Hyper Threading, I think that SMP support provides more benefit than tickless.

Also, I prefer a single kernel version--part of Puppy's appeal is it's simplicity -- KISS!

Posted on 26 Aug 2008, 11:24 by Raffy
kernel news
Today, news about 2.6.27 kernel is in the Forum:

Quote: <i>I do feel bad making a suggestion of this type while Barry is recovering from his teeth-pulling, but I'd like to put in a plug for the 2.6.27 kernel in Puppy 4.1. The current Fedora Rawhide version (2.6.27-0.275.rc4.git2.fc10.i686) works with all three of my problem-children wireless cards (a generic Atheros 2413-based card in my desktop PC, a Ralink 2500-based card in my Averatec laptop, and my brand new Acer Aspire One with its newer Atheros-based wireless unit.</i>