<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
<blockquote type="cite"><br>
However sometimes the computer takes a very long time (20
seconds to -- I think -- 15 minutes or more) to react to a
change in the load. I have run commands like "stress --cpu 1" or
"stress --cpu 8" and watched i7z. When the governor is
powersave it may stay at 800MHz and when the governor is
performance it may stay between 1000MHz to 1400MHz. If I leave
the stress running long enough it seems like eventually the
frequency will go up to the expected values. Once the CPU
frequency goes up I can keep it up by leaving the stress running
and my applications are responsive. If I kill the stress
process, the system may or may not respond quickly to changes in
load.
</blockquote>
<br>
I thought that I would give my current best work-around to this
problem for any future googler who has the same problem. This
solution is looking like it is good enough to keep. It is based
on experimentation without any understanding of the underlying
mechanics.<br>
<br>
I have put the lines <br>
<blockquote>
<pre>for i in 0 1 2 3 4 5
do
/usr/bin/cpupower -c 6 idle-set --disable $i
done
/usr/bin/cpupower frequency-set -g powersave
</pre>
</blockquote>
into my rc.local script. I have noticed before that disabling
idle states seems to mean that once the cpu frequency becomes
responsive to cpu load it remains responsive to cpu load. But
without the "-c 6" the machine ran somewhat hot whereas with the
"-c 6" the machine seems to cool down pretty well when it is
idle. I don't think that the powersave line is necessary because
I think that powersave is the default. I am wondering if "-c 0"
would be better but I will experiment with that later.<br>
<br>
I also have some other lines in my rc.local suggested by powertop
but I don't think that these lines are making any difference to my
problem:<br>
<br>
<blockquote>
<pre>#
# disable nmi watchdog (powertop)
#
echo '0' > /proc/sys/kernel/nmi_watchdog
#
# VM writeback timeout
#
echo '1500' > '/proc/sys/vm/dirty_writeback_centisecs'
</pre>
</blockquote>
<br>
-Timothy <br>
<br>
<br>
On 11/12/2014 07:52 PM, Timothy Redmond wrote:<br>
</div>
<blockquote cite="mid:54642AFB.5050702@yahoo.com" type="cite">
<br>
I have a Thinkpad W520 computer (4270CTO) and I am running Fedora
20 and keeping its packages up to date. Often when I am working
the cpu frequency transitions beautifully and the computer is very
responsive. I have run some programs that take a long time (hours
to days) and have watched the frequency go up when there is only
one thread running and go down when there are several threads
running. So it seems to be working very nicely.
<br>
<br>
However sometimes the computer takes a very long time (20 seconds
to -- I think -- 15 minutes or more) to react to a change in the
load. I have run commands like "stress --cpu 1" or "stress --cpu
8" and watched i7z. When the governor is powersave it may stay at
800MHz and when the governor is performance it may stay between
1000MHz to 1400MHz. If I leave the stress running long enough it
seems like eventually the frequency will go up to the expected
values. Once the CPU frequency goes up I can keep it up by
leaving the stress running and my applications are responsive. If
I kill the stress process, the system may or may not respond
quickly to changes in load.
<br>
<br>
There is some googleable discussion about the BIOS limiting the
frequency for Thinkpads. However, the value in
<br>
<br>
/sys/module/processor/parameters/ignore_ppc
<br>
<br>
<br>
does not seem to matter though and the file
<br>
<br>
/sys/devices/system/cpu/cpu0/cpufreq/bios_limit
<br>
<br>
<br>
is never present. Also the system will respond when I change the
governor from performance to powersave and back which does not
seem consistent with a limit provided by the BIOS.
<br>
<br>
Does anyone know what could be wrong or how I can debug this?
<br>
<br>
-Timothy
<br>
<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>