From: Frans Pop <elendil@planet.nl>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [SOMEWHAT SOLVED] Niced processes do not raise CPU frequency with ondemand
Date: Sat, 13 Jun 2009 20:01:01 +0200 [thread overview]
Message-ID: <200906132001.02828.elendil@planet.nl> (raw)
In-Reply-To: <200906122005.02965.elendil@planet.nl>
On Friday 12 June 2009, Frans Pop wrote:
> On Friday 12 June 2009, Pallipadi, Venkatesh wrote:
> > On Fri, 2009-06-12 at 10:25 -0700, Frans Pop wrote:
> > > On Friday 12 June 2009, Pallipadi, Venkatesh wrote:
> > > > What does ignore_nice under cpufreq/ondemand say?
> > >
> > > Right, that's 1 (was not aware that existed :-P)
> > > And changing it to 0 solves the problem.
> >
> > > Next question is: how and why does it get set?
> > > As userland has not changed (AFAIK), my first suspect remains the
> > > kernel.
> >
> > Kernel never sets this. It is initialized to 0 and provides a /sys
> > interface to user. I think it is set by some user app
> > (gnome-power-manager or some other app like that). That explains why
> > it is 0 initially after boot and gets changed later.
I think I have it figured out.
HAL has a method 'SetCPUFreqConsiderNice' which writes the file.
I use KDE's kpowersave, which has some code that calls that method through
dbus and sets the value to the value of a function getAcAdapter().
I.e, the intention seems to be to ignore niced processes when not on AC
(if I understand Matthew Garrett's blog posts correctly that is probably
not even correct policy, but let's ignore that for now).
But it also looks like the whole implementation, either in kpowersave or
in hal/dbus (or quite likely all three), is so crap that ignore_nice only
actually does get set if the moon is in phase with Saturn or something
like that. At least, I've tried undocking my notebook (removed AC) a few
times without seeing any change in ignore_nice.
I've got an inotify on the file now, so I should get some info next time
the setting does get changed. Possibly that will confirm this theory.
After that I'll probably change the kpowersave source and remove the code
that changes the setting.
Thanks again for the pointers!
Cheers,
FJP
prev parent reply other threads:[~2009-06-13 18:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 16:44 [BUG][2.6.30] Niced processes do not raise CPU frequency with ondemand Frans Pop
2009-06-12 16:48 ` Pallipadi, Venkatesh
2009-06-12 17:25 ` Frans Pop
2009-06-12 17:41 ` Pallipadi, Venkatesh
2009-06-12 18:05 ` Frans Pop
2009-06-13 18:01 ` Frans Pop [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200906132001.02828.elendil@planet.nl \
--to=elendil@planet.nl \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=venkatesh.pallipadi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox