3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Toralf Förster]

The following file doesn't exists at my Gentoo Linux
/sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
in 3.9.0 if I activate CONFIG_X86_INTEL_PSTATE=y 

That means, that a command like

$> echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load

in /etc/rc.local is now no longer working.
A high fan +  high temperature are the result, even if just the BOINC client
is run with low prio (nice 19) in the back ground.

Manually loading the missing module won't work too :

$> modprobe acpi_cpufreq
modprobe: ERROR: could not insert 'acpi_cpufreq': Device or resource busy

Is the behaviour a bug or a feature ?
In the later case: How can I achieve the previous behaviour back ?

This issue might affect the RH EL kernel too [1] where I observed a similar behaviour.


[1] http://elrepo.org/bugs/view.php?id=379

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Rafael J. Wysocki]

On Friday, May 03, 2013 06:55:37 PM Toralf Förster wrote:
> The following file doesn't exists at my Gentoo Linux
> /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
> in 3.9.0 if I activate CONFIG_X86_INTEL_PSTATE=y 
> 
> That means, that a command like
> 
> $> echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
> 
> in /etc/rc.local is now no longer working.
> A high fan +  high temperature are the result, even if just the BOINC client
> is run with low prio (nice 19) in the back ground.
> 
> Manually loading the missing module won't work too :
> 
> $> modprobe acpi_cpufreq
> modprobe: ERROR: could not insert 'acpi_cpufreq': Device or resource busy
> 
> Is the behaviour a bug or a feature ?

The thermal management problem is not an intentional outcome, definitely.

> In the later case: How can I achieve the previous behaviour back ?
> 
> This issue might affect the RH EL kernel too [1] where I observed a similar behaviour.
> 
> 
> [1] http://elrepo.org/bugs/view.php?id=379

Dirk, is this the problem we were talking about recently or something else?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Dirk Brandewie]

On 05/03/2013 12:36 PM, Rafael J. Wysocki wrote:
> On Friday, May 03, 2013 06:55:37 PM Toralf Förster wrote:
>> The following file doesn't exists at my Gentoo Linux
>> /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
>> in 3.9.0 if I activate CONFIG_X86_INTEL_PSTATE=y
>>
>> That means, that a command like
>>
>> $> echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
>>
>> in /etc/rc.local is now no longer working.
>> A high fan +  high temperature are the result, even if just the BOINC client
>> is run with low prio (nice 19) in the back ground.
>>


ignore_nice_load is a feature of the ondemand governor.

The intel_pstate driver is seeing the load presented by the BOINC client and
is adjusting the pstate accordingly.

>> Manually loading the missing module won't work too :
>>
>> $> modprobe acpi_cpufreq
>> modprobe: ERROR: could not insert 'acpi_cpufreq': Device or resource busy
>>
>> Is the behaviour a bug or a feature ?

The intel_pstate drive has already registered as a scaling driver so when
acpi_cpufreq tries to register as a scaling driver the registration fails

>
> The thermal management problem is not an intentional outcome, definitely.
>
>> In the later case: How can I achieve the previous behaviour back ?
>>

If you require the ondemand governor you can remove CONFIG_X86_INTEL_PSTATE
from your configuration or add "intel_pstate=disable" to your kernel command
line.

--Dirk
>> This issue might affect the RH EL kernel too [1] where I observed a similar behaviour.
>>
>>
>> [1] http://elrepo.org/bugs/view.php?id=379
>
> Dirk, is this the problem we were talking about recently or something else?
>
> Rafael
>
>

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Toralf Förster]

On 05/03/2013 11:10 PM, Dirk Brandewie wrote:
> 
> ignore_nice_load is a feature of the ondemand governor.
> The intel_pstate driver is seeing the load presented by the BOINC client
> and is adjusting the pstate accordingly.

Is the intel_pstate driver a choice for a notebook and friends where a
grid software is running as a low-prio back ground job ?

Because the CPU will be running mostly at high(er) frequency - which
always results in a high temperature and short battery time.

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Dirk Brandewie]

On 05/03/2013 02:26 PM, Toralf Förster wrote:
> On 05/03/2013 11:10 PM, Dirk Brandewie wrote:
>>
>> ignore_nice_load is a feature of the ondemand governor.
>> The intel_pstate driver is seeing the load presented by the BOINC client
>> and is adjusting the pstate accordingly.
>
> Is the intel_pstate driver a choice for a notebook and friends where a
> grid software is running as a low-prio back ground job ?
>

Probably not.

> Because the CPU will be running mostly at high(er) frequency - which
> always results in a high temperature and short battery time.
>

It would be better IMHO if the client software limited the resources
it uses when the system is not on wall power but that is a seperate
discussion :-)

--Dirk

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Toralf Förster]

On 05/03/2013 11:43 PM, Dirk Brandewie wrote:
> On 05/03/2013 02:26 PM, Toralf Förster wrote:
>> On 05/03/2013 11:10 PM, Dirk Brandewie wrote:
>>>
>>> ignore_nice_load is a feature of the ondemand governor.
>>> The intel_pstate driver is seeing the load presented by the BOINC client
>>> and is adjusting the pstate accordingly.
>>
>> Is the intel_pstate driver a choice for a notebook and friends where a
>> grid software is running as a low-prio back ground job ?
>>
> 
> Probably not.

Hhm.

The kernel menuconfig says :

 This driver provides a P state for Intel core processors
 The driver implements an internal governor and will become
 the scaling driver and governor for Sandy bridge processors.


What shall a company like IBM with a lot of notebook installation running BOINC
in the back ground process (World Community Grid) do - what's the consequence for
those installations if they will have that a processor ?

In the past (few years ago and related to the ondemand governor IIRC) there were
already a longer discussion about the "nice -n 19" topic and the result was
to support it.

/me Cc:'ing boinc devs, the topic might be interesting for them too.


>> Because the CPU will be running mostly at high(er) frequency - which
>> always results in a high temperature and short battery time.
>>
> 
> It would be better IMHO if the client software limited the resources
> it uses when the system is not on wall power but that is a seperate
> discussion :-)
> 
> --Dirk
> 
> 


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Rafael J. Wysocki]

On Saturday, May 04, 2013 09:57:54 AM Toralf Förster wrote:
> On 05/03/2013 11:43 PM, Dirk Brandewie wrote:
> > On 05/03/2013 02:26 PM, Toralf Förster wrote:
> >> On 05/03/2013 11:10 PM, Dirk Brandewie wrote:
> >>>
> >>> ignore_nice_load is a feature of the ondemand governor.
> >>> The intel_pstate driver is seeing the load presented by the BOINC client
> >>> and is adjusting the pstate accordingly.
> >>
> >> Is the intel_pstate driver a choice for a notebook and friends where a
> >> grid software is running as a low-prio back ground job ?
> >>
> > 
> > Probably not.
> 
> Hhm.
> 
> The kernel menuconfig says :
> 
>  This driver provides a P state for Intel core processors
>  The driver implements an internal governor and will become
>  the scaling driver and governor for Sandy bridge processors.
> 
> 
> What shall a company like IBM with a lot of notebook installation running BOINC
> in the back ground process (World Community Grid) do - what's the consequence for
> those installations if they will have that a processor ?
> 
> In the past (few years ago and related to the ondemand governor IIRC) there were
> already a longer discussion about the "nice -n 19" topic and the result was
> to support it.
> 
> /me Cc:'ing boinc devs, the topic might be interesting for them too.

One option might be to use the powerclamp driver along with intel_pstate to
reduce the heat dissipation.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Dirk Brandewie]

On 05/03/2013 12:36 PM, Rafael J. Wysocki wrote:
> On Friday, May 03, 2013 06:55:37 PM Toralf Förster wrote:
>> The following file doesn't exists at my Gentoo Linux
>> /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
>> in 3.9.0 if I activate CONFIG_X86_INTEL_PSTATE=y
>>
>> That means, that a command like
>>
>> $> echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
>>
>> in /etc/rc.local is now no longer working.
>> A high fan +  high temperature are the result, even if just the BOINC client
>> is run with low prio (nice 19) in the back ground.
>>
>> Manually loading the missing module won't work too :
>>
>> $> modprobe acpi_cpufreq
>> modprobe: ERROR: could not insert 'acpi_cpufreq': Device or resource busy
>>
>> Is the behaviour a bug or a feature ?
>
> The thermal management problem is not an intentional outcome, definitely.
>
>> In the later case: How can I achieve the previous behaviour back ?
>>

I spent some more time looking for a solution to this you can get same behavior
by setting a config option in BOINC  "Use at most X % CPU time"
see: http://boinc.berkeley.edu/wiki/Local_preferences


>> This issue might affect the RH EL kernel too [1] where I observed a similar behaviour.
>>
>>
>> [1] http://elrepo.org/bugs/view.php?id=379
>
> Dirk, is this the problem we were talking about recently or something else?
>
> Rafael
>
>

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Toralf Förster]

On 05/13/2013 06:43 PM, Dirk Brandewie wrote:
> I spent some more time looking for a solution to this you can get same
> behavior
> by setting a config option in BOINC  "Use at most X % CPU time"

yes - that's true. But BOINC is just an example.

If "nice -19 <loooong running background job" is nowadays so uncommon,
then I'm just curious what's the modern (easy) way of doing that ?

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Dirk Brandewie]

On 05/13/2013 10:20 AM, Toralf Förster wrote:
> On 05/13/2013 06:43 PM, Dirk Brandewie wrote:
>> I spent some more time looking for a solution to this you can get same
>> behavior
>> by setting a config option in BOINC  "Use at most X % CPU time"
>
> yes - that's true. But BOINC is just an example.
>
> If "nice -19 <loooong running background job" is nowadays so uncommon,
> then I'm just curious what's the modern (easy) way of doing that ?
>

I believe using CGROUP's is the right answer for limiting this type
of load.

I have not tested it but from reading:
	Documentation/scheduler/sched-design-CFS.txt
	https://wiki.archlinux.org/index.php/Cgroups

You should be able to do something like the following:

	cd /sys/fs/cgroup/cpu
	mkdir bonic
	echo 400 > boinc/cpu.shares
	boinc &
	echo $! > boinc/tasks

Should limit the boinc group to ~40% of the cpu.

WARNING completely untested YMMV

--Dirk

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Toralf Förster]

On 05/13/2013 07:57 PM, Dirk Brandewie wrote:
>     cd /sys/fs/cgroup/cpu
>     mkdir bonic
>     echo 400 > boinc/cpu.shares
>     boinc &
>     echo $! > boinc/tasks

In many places of my scripts for automated testing I use currently the
"nice -n" prefix at my ThinkPad to keep a long battery life, quiet fan,
cool CPU. The CPU just runs with minimal frequency but will give
med/max. power on demand.

If the P-State governor will be the replacement the old behaviour -

the kernel menu config says "will become the perferred ... (sic!)
...scaling driver for Sandy bridge processors" -

is there a nifty user space tool which replaces "nice" and do all cgroup
stuff for the user ?

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Dirk Brandewie]

On 05/13/2013 12:13 PM, Toralf Förster wrote:
> On 05/13/2013 07:57 PM, Dirk Brandewie wrote:
>>      cd /sys/fs/cgroup/cpu
>>      mkdir bonic
>>      echo 400 > boinc/cpu.shares
>>      boinc &
>>      echo $! > boinc/tasks
>
> In many places of my scripts for automated testing I use currently the
> "nice -n" prefix at my ThinkPad to keep a long battery life, quiet fan,
> cool CPU. The CPU just runs with minimal frequency but will give
> med/max. power on demand.
>
> If the P-State governor will be the replacement the old behaviour -
>
> the kernel menu config says "will become the perferred ... (sic!)
> ...scaling driver for Sandy bridge processors" -
>
> is there a nifty user space tool which replaces "nice" and do all cgroup
> stuff for the user ?
>

cgexec from the libcgroup-tools package (fedora name) look like it will place
a process in a group for you.

https://wiki.archlinux.org/index.php/Cgroups

Has some useful examples.

--Dirk

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Toralf Förster]

On 05/13/2013 09:24 PM, Dirk Brandewie wrote:
> On 05/13/2013 12:13 PM, Toralf Förster wrote:
>> On 05/13/2013 07:57 PM, Dirk Brandewie wrote:
>>>      cd /sys/fs/cgroup/cpu
>>>      mkdir bonic
>>>      echo 400 > boinc/cpu.shares
>>>      boinc &
>>>      echo $! > boinc/tasks
>>
>> In many places of my scripts for automated testing I use currently the
>> "nice -n" prefix at my ThinkPad to keep a long battery life, quiet fan,
>> cool CPU. The CPU just runs with minimal frequency but will give
>> med/max. power on demand.
>>
>> If the P-State governor will be the replacement the old behaviour -
>>
>> the kernel menu config says "will become the perferred ... (sic!)
>> ...scaling driver for Sandy bridge processors" -
>>
>> is there a nifty user space tool which replaces "nice" and do all cgroup
>> stuff for the user ?
>>
> 
> cgexec from the libcgroup-tools package (fedora name) look like it will
> place
> a process in a group for you.
> 
> https://wiki.archlinux.org/index.php/Cgroups
> 
> Has some useful examples.
> 
> --Dirk
> 

I'm not really convinced about using P-State in favour of ondemand -
with the cpu ondemand governor my freshly booted system with just KDE
started stays here around 39°C - with pstate I do have 53°C.

Even more if I run BOINC the temperature is around 92° even with these
settings :

 tail -v /sys/fs/cgroup/cpu/groupname/boinc/*
==> /sys/fs/cgroup/cpu/groupname/boinc/cgroup.clone_children <==
0

==> /sys/fs/cgroup/cpu/groupname/boinc/cgroup.event_control <==
tail: error reading
‘/sys/fs/cgroup/cpu/groupname/boinc/cgroup.event_control’: Invalid argument

==> /sys/fs/cgroup/cpu/groupname/boinc/cgroup.procs <==
3411
3415
3416
3417
3419
3421
3422
3423
3434
3435

==> /sys/fs/cgroup/cpu/groupname/boinc/cpu.cfs_period_us <==
100000

==> /sys/fs/cgroup/cpu/groupname/boinc/cpu.cfs_quota_us <==
-1

==> /sys/fs/cgroup/cpu/groupname/boinc/cpu.shares <==
2

==> /sys/fs/cgroup/cpu/groupname/boinc/cpu.stat <==
nr_periods 0
nr_throttled 0
throttled_time 0

==> /sys/fs/cgroup/cpu/groupname/boinc/notify_on_release <==
0

==> /sys/fs/cgroup/cpu/groupname/boinc/tasks <==
3417
3418
3419
3420
3421
3422
3423
3424
3434
3435


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: 3.9.0 + CONFIG_X86_INTEL_PSTATE=y -> ThinkPad T420 with i5 lost ACPI functionality

[Toralf Förster]

On 05/28/2013 08:11 PM, Toralf Förster wrote:
> cgexec from the libcgroup-tools package (fedora name) look like it will
>> place
>> a process in a group for you.
>> 
>> https://wiki.archlinux.org/index.php/Cgroups
>> 
>> Has some useful examples.
>> 
>> --Dirk
>> 

What I'm looking for is a command telling the governor "do not increase
CPU frequency for this process (group)" - because that's the main
intention of "nice -19", right ?

Without such a simple-to-use-command/replacement-of-nice-19 a lot of
systems in the wild won't work as expected with the p-state driver in
place of acpi_cpufreq.

(And AFAICR this was one of those reasons why for ondemand the
"ignore_nice" sysfs feature was implemented)

Especially RedHat systems using the  kernel-ml will automatically switch
to p-state - pretty sure, that's not wanted by a reasonable amount of
people, or ?

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3