Increasing CONFIG_HZ on Arch ARM kernels

[soundcheck]

Hi there.

The scheduler base frequency chosen on ARM kernels, and here the RPI kernel in particular, is 100Hz.
That means we're facing a 10ms scheduling interval.

Such a low setting is ususally recommended for server usage. (My experience: Higher settings won't cause issues on servers either.)

The 100Hz has also been the default and even hardcoded ARM kernel setting for quite some time in the past.

With the new 3.12/3.16 kernels (on the RPI) we can change this CONFIG_HZ setting.
On older and still used kernels like 3.4, kernel sources could easily patched. I did this for my own custom Cubitruck kernel.

Choosing 250 or 300Hz instead of 100Hz will speed up the scheduling interval.
I'd guess most applications on these low-muscle ARM devices will benefit.
Things will get more responsive since latencies get lowered.

What do you guys think about introducing such an easy to accomplish change to the default kernel configurations???

Cheers

[pepedog]

Got a reference for this?

[soundcheck]

It's not been a hot topic by now. I'd guess there's not much written about it.

I supplied a patch in the Cubitruck forums.

That setting is used now for one of the popular Debian Wheezy images and for a Minimal Arch image project over there.

These are the two projects:

http://www.cubieforums.com/index.php/topic,1275.0.html
http://www.cubieforums.com/index.php?topic=1592.0

Since I'm currently playing around with the RPI B+, I compiled the 3.16 latest for the RPI myself and changed it to 300Hz.
I realized that the new kernel doesn't have the 100Hz hardcoded anymore.

I think this subject is more imortant then e.g. a BFQ patch.

Cheers

[moonman]

It might be a more important topic to you, but not anyone else. With higher tick frequency you are sacrificing throughput. You will most definitely benefet from lower latency as you are.using rpi for audio bit what about the rest who could care less about latency?

http://www.makelinux.net/books/lkd2/ch10lev1sec2

[bodhi]

Sounds like soundcheck should use PREEMPT-RT.

[soundcheck]

I think the article moonman is refering to clearly states the advantages about higher HZ.
With nowadays DynTicks the mentioned slight overhead even gets reduced.


Have you ever asked yourself what's behind the kernel setting low-latency-desktop ??

A desktop plus the base OS apps plus user apps running numerous tasks.
A busy server will face a similar situation. The low HZ setting will cause additional
overhead. Over time buffers, caches fill up and processes running more and more waiting loops.

On a 8-core Intel Haswell wih 8GB RAM you wouldn't notice. On a weak ARM you will.

I'm not considering the rt-patch as a solution for a general purpose machine.
The rt-patch is meant for single purpose devices.

My intention was not to "sell" the higher HZ setting. It's meant to be a constuctive feedback.

Perhaps you (the guys in charge of the kernels) just put an optional low-latency-300Hz kernel into the repo.
It just need two changes in the .config. That's a nobrainer. People quickly will tell if it is worth it.

The whole thing doesn't apply to me anyhow. I'm configuring, slimning down by 2/3 and patching my own kernels anyhow.

Enjoy.

[bodhi]

$this->bbcode_second_pass_quote('soundcheck', '
')My intention was not to "sell" the higher HZ setting. It's meant to be a constuctive feedback.

[moonman]

Sounds reasonable. Don't get me wrong, if it works as well as you describe it then great, but I have a feeling it is not that simple. What concerns me is that the overhead on the underpowered rpi might actually be noticeable(/huge?). Also I did play with this config option a while back and ended up with an unstable laptop with certain kernel modules not behaving like they should.
I don't have my pri to test anymore as I put it in my car. What do others think? Someone wants to test this?

[pepedog]

I just did a git clone of PKGBUILDs and was surprised by what grep -r CONFIG_HZ= threw up
Knew about linux-imx6-cubox-dt/config:CONFIG_HZ=1000 but all other distro for that platform has it too
$this->bbcode_second_pass_code('', ' grep -r CONFIG_HZ=
linux-sun7i/config:CONFIG_HZ=100
linux-armv7/config:CONFIG_HZ=200
linux-odroid-xu-mainline/config:CONFIG_HZ=200
linux-kirkwood/config:CONFIG_HZ=100
linux-chromebook/config:CONFIG_HZ=200
linux-sun4i/config:CONFIG_HZ=100
linux-raspberrypi-latest/config:CONFIG_HZ=100
linux-armv7-rc/config:CONFIG_HZ=200
linux-omap/config:CONFIG_HZ=128
linux-parallella/config:CONFIG_HZ=100
linux-boundary/config:CONFIG_HZ=100
linux-utilite/config:CONFIG_HZ=100
linux-am33x/config:CONFIG_HZ=100
linux-sun5i/config:CONFIG_HZ=100
linux-udoo/config:CONFIG_HZ=100
linux-cubox/config:CONFIG_HZ=100
linux/archlinuxarm.patch:+CONFIG_HZ=100
linux/config:CONFIG_HZ=100
linux-sun5i-staging/config:CONFIG_HZ=100
linux-trimslice/config:CONFIG_HZ=100
linux-kirkwood-dt/config:CONFIG_HZ=100
linux-d3plug/config:CONFIG_HZ=100
linux-imx6-cubox-dt/config:CONFIG_HZ=1000
linux-cubox-headless/config:CONFIG_HZ=100
linux-armv5-test/config:CONFIG_HZ=100
linux-odroid-xu/config:CONFIG_HZ=200
linux-armv5/config:CONFIG_HZ=100
linux-mmp/config:CONFIG_HZ=100
linux-armv5-rc/config:CONFIG_HZ=100
linux-odroid-xu3/config:CONFIG_HZ=200
linux-imx6-cubox/config:CONFIG_HZ=100
linux-odroid-xu-headless/config:CONFIG_HZ=200
linux-chromebook2/config:CONFIG_HZ=200
linux-raspberrypi/config:CONFIG_HZ=100
linux-zedboard/config:CONFIG_HZ=100
linux-wandboard/config:CONFIG_HZ=100
linux-radxa/config:CONFIG_HZ=100
linux-am33x-legacy/config:CONFIG_HZ=512
linux-odroid/config_x2:CONFIG_HZ=200
linux-odroid/config_u2:CONFIG_HZ=200
linux-odroid/config_x:CONFIG_HZ=200
linux-oxnas/config:CONFIG_HZ=100')

[Socaltom]

Interesting. I've found that motion can handle up to 4 IP cameras on my V3 Pogoplug pro. ( dual cpu @850 mhz), but not on the 1600 mhz Zyxel NAS325. It only takes 50% CPU on the Zyxel, but the CPU load is over 1, and continues to grow. Would changing the Confif_HZ to 200 from 100 improve the rate it handles those activities?
Tom