ignore_nice_load ignored in processor scaling

Bug #368809 reported by Evan Huus on 2009-04-28
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
linux (Ubuntu)
Undecided
Unassigned
Jaunty
Medium
Manoj Iyer

Bug Description

Binary package hint: kernel

Up-to-date Jaunty. Intel Q6600, 2.4GHz

When ignore_nice_load is set to 1 on my cpu, nice processes (BOINC, running at nice 19) still scale up the CPU.

sam tygier (samtygier) wrote :

i guess the argument for the change would be that you can do the same work in less time, and using less power at a higher clock speed. so if you can do N units per day with the CPU at its lowest speed, then you could save some power by doing those N units in 6 hours, and letting the CPU (or even better the whole machine) sleep the rest of the day.

Evan Huus (eapache) wrote :

Sam, that is a good argument for keeping it turned off by default. However, if I turn it on manually, it ought to keep them scaled down, because that's what I specifically told it to do.

Rkimber (rkimber) wrote :

Is this the cause of my problem?

I have noticed that since upgrading to Ubuntu 9.04, when running Boinc, my CPUs are running about 14 degrees C hotter (at about 52C to 56C, compared with roughly 38C to 43C before). When not running Boinc and not using other apps, temperatures look much as they did before (28C to 34C).

Top reports boinc NI as 19, other apps seem to be 0, and system stuff is all -5

I haven't noticed any reduction in processing time, though I don't have any actual record to compare and don't actually know that I'm being sent the same types of boinc jobs as before.

Rkimber (rkimber) wrote :

I've discovered that the behaviour of the CPU frequency settings has changed. The monitor applet offers 4 settings: "conservative", "ondemand", "performance", and "powersave".

Previously, the "ondemand" setting only pushed cpu frequency up to 100% when I invoked a foreground process, like indexing a lot of usenet articles. Boinc processes niced at 19, which ran all the time, were run at a lower frequency.

Now, "ondemand" seems to run Boinc (NI 19) at 100%, and when boinc is not running and I invoke other processes (NI 0) it seems, subjectively, much slower to push up to 100% than before, though that might be a function of the monitor applet.

As far as I can see on my PC, there isn't any practical difference between "conservative" and "powersave", nor between "ondemand" and "performance" when I'm running something like boinc that runs continually.

I haven't yet located the documentation that defines these governors and how they should work.

Evan Huus (eapache) wrote :

Rkimber, I find that

http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html

does a good job of explaining things.

As far as I can tell, there is a value which determines whether or not nice processes (like BOINC) are allowed to scale the CPU or not. The default value of this has changed, which is what is the cause of your problem. The bug I am reporting however, is that even when I manually turn this value on, BOINC still scales the CPU.

If this problem occurs on your machine after having manually set this value, please say so.

Rkimber (rkimber) wrote :

Thanks for making things clear.

I have done:
sudo sh -c "echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load"
and can confirm that the boinc processes are run at full frequency on my amd64x2 (2.2Ghz)

Rkimber (rkimber) wrote :

I'm not an expert about these things, but wouldn't this be a kernel bug, rather than cpufreqd?

Rkimber (rkimber) on 2009-05-04
description: updated
swalker (sdwalker) wrote :

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=1ca3abdb6a4b87246b00292f048acd344325fd12

[CPUFREQ] Make ignore_nice_load setting of ondemand work as expected.

ondemand micro-accounting of idle time changes broke ignore_nice_load
sysfs setting due to a thinko in the code.

The bug entry:
http://bugzilla.kernel.org/show_bug.cgi?id=12310

Backport the change to Jaunty?

Rkimber (rkimber) wrote :

I hope so.

Changed in linux:
status: Unknown → Fix Released

I'm reassigning this to the kernel. swalker, thanks for the reference to the patch. I'll leave it to the discretion of the Ubuntu kernel team if this will qualify for an SRU for Jaunty, but I'll go ahead and open a Jaunty nomination for their consideration. Against karmic this should be Fix Released. Thanks.

affects: cpufreqd (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu Jaunty):
importance: Undecided → Medium
status: New → Triaged

Would be nice though to have someone test the latest Karmic kernel just to confirm it's resolved.

Changed in linux (Ubuntu):
status: New → Fix Released
Manoj Iyer (manjo) on 2009-06-15
Changed in linux (Ubuntu Jaunty):
assignee: nobody → Manoj Iyer (manjo)
Manoj Iyer (manjo) wrote :

Can you please test the jaunty kernel in

http://people.ubuntu.com/~manjo/lp368809-jaunty/

and report back here ?

Manoj Iyer (manjo) wrote :

Waiting on test results from the originator of the bug.

Changed in linux (Ubuntu Jaunty):
status: Triaged → Incomplete
Evan Huus (eapache) wrote :

I'm sorry, I'm very busy right now changing jobs. I'll try and get around to it this weekend if not before.

It is on my to-do list.

Evan Huus (eapache) wrote :

The given directory only has linux-image-generic and linux-headers-generic.

dpkg: dependency problems prevent configuration of linux-headers-2.6.28-14-generic:
linux-headers-2.6.28-14-generic depends on linux-headers-2.6.28-14;

Should I force it, or do you need to provide a linux-headers package as well?

Manoj Iyer (manjo) wrote :

I will upload the headers as well...

Manoj Iyer (manjo) wrote :

Packages uploaded.

linux-headers-2.6.28-14-generic_2.6.28-14.45~lp368809manjo1_amd64.deb
linux-headers-2.6.28-14_2.6.28-14.45~lp368809manjo1_all.deb
linux-image-2.6.28-14-generic_2.6.28-14.45~lp368809manjo1_amd64.deb

Evan Huus (eapache) wrote :

The provided kernel does not fix the issue on my machine. BOINC processes (nice 19) still scale up the cpu frequency. I have double-checked the package version and rebooted twice.

Additionally, it does something funny to usplash. It no longer shows any progress, the bar bounces back and forth the entire time instead.

Manoj Iyer (manjo) wrote :

hmm.. I built that kernel with the patch mentioned here that said to have fixed the problem in upstream kernel.

Evan Huus (eapache) wrote :

Oops. Erm, it does work, my mistake. I forgot to turn ignore_nice_load back on via /sys/devices

Also, the usplash thing seems to have fixed itself after a few more boot cycles. No idea what happened there.

Tessa (unit3) wrote :

Any idea on when this'll be pushed out into backports or whatever? I just got bitten with this bug myself. :)

Manoj Iyer (manjo) wrote :

Submitted SRU for Jaunty.

Tessa (unit3) wrote :

Anyone know if this made it in to a kernel package yet or not? I'm still seeing this behaviour on 2.6.28-15, jaunty/i686.

Evan Huus (eapache) wrote :

It hasn't made it in yet, thus the "Incomplete" status for the Jaunty portion of the bug. I'm not holding out much hope.

I am in the middle of writing a script which will automatically patch whatever kernel you're currently running though. When I'm done I'll post it here and you should just be able to download and run it to get a patched version of the kernel.

Tessa (unit3) wrote :

Gotcha. Thanks, eapache!

Evan Huus (eapache) wrote :

Here's the patch...

Evan Huus (eapache) wrote :

And here's the script.

Just make sure that the ignore_nice_load.patch file is in the PATCH_DIR, and that the BUILD_DIR has a decent amount of free space. You may also want to change CONCURRENCY_LEVEL to suit the number of processing cores you have.

This has not been extensively tested (I used it exactly once to build my current kernel), so use at your own risk.

Kolargol00 (kolargol00) wrote :

Still not fixed in Jaunty... :/
(Linux Macharia 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20 19:48:24 UTC 2009 i686 GNU/Linux)

Tessa (unit3) wrote :

Just checked on my server in karmic, and this does appear to be fixed there.

Changed in linux:
importance: Unknown → Medium
Evan Huus (eapache) wrote :

Jaunty is end-of-life. Expiring this task.

Changed in linux (Ubuntu Jaunty):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.