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
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.
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
>
>
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
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
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
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.
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
>
>
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
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
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
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
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
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