Andre Balsa wrote:
>OTOH when the clock is _stopped_ (e.g. APM), the Centaur, just like the
>Intel and the AMD K5/K6, will dissipate around 350 mW. However, coming
>out of a clock stop condition is expensive in terms of clock cycles,
>because the CPU internal clock PLL must re-synchronize with the external
>clock input.
>The Cyrix 6x86 is unique in its ability to power down when Halted and
^^^^ should this read 6x86MX ?
>wake up again without a single CPU clock cycle loss.
I wrote the following script to verify this, using the most acclaimed of
all bechmarks: make zImage
...and on an otherwise quiescent system the CPU is quite idle while doing
a kernel build, specially if you have slow disks like mine, and don't use
the "make -j" trick. On another VT I could see (using top) that the CPU
was idle between 15-95%, averaging around 60%.
----------------- begin script -------------------
#!/bin/bash
cd /usr/src
echo "w/o suspend-on-halt" > results
for i in 1 2 3 ; do
echo "run ${i}:" >> results
(cd linux ; make clean ;
{ time make zImage ; } 2>&1 | tail --lines 3 >> ../results)
done
echo "w/ suspend-on-halt" >> results
set6x86 -p 0xc2 -s 8 # enable suspend on halt
for i in 1 2 3 ; do
(cd linux ; make clean ;
{ time make zImage ; } 2>&1 | tail --lines 3 >> ../results)
echo "run ${i}:" >> results
done
------------------------ end script ------------------------
The human-formatted results are the following (real time only):
w/o suspend-on-halt w/ suspend-on-halt
run 1: 7m11.909s 7m2.777s
run 2: 7m4.120s 7m3.221s
run 3: 7m2.413s 7m3.431s
[System: Cyrix 6x86MX 200PR+, FIC PA2012 Motherboard, 32MB SDRAM,
3.1GB WD HD, Linux 2.102]
No difference at all! And during idle time the CPU is only consuming
350mW, why do people insist on calling this a bug? Moreover on power up,
suspend-on-halt is disabled, so there is no incompatability unless you
fool around with the configuration registers. Let me repeat that, on
power up the TSC is behaves *exactly* as the Intel Pentium TSC.
Now it is clear that as the kernel stands we cannot have both Cyrix
Suspend-OH and do_fast_gettimeoffset [1], but this only affects those who
like to mess around with their CPUs, the risks are known to us.
Could we go back the previous behavior?
Cheers,
[1] until someone steps forwards with a patch of course.
-- Rafael
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu