lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200906132001.02828.elendil@planet.nl>
Date:	Sat, 13 Jun 2009 20:01:01 +0200
From:	Frans Pop <elendil@...net.nl>
To:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [SOMEWHAT SOLVED] Niced processes do not raise CPU frequency with ondemand

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ