5-STABLE cpufreq hotter than est from ports

[Kevin Oberman]

> From: Tijl Coosemans <tijl at ulyssis.org>
> Date: Mon, 8 Aug 2005 16:18:00 +0200
> 
> Kevin,
> 
> Thanks for your reply. I was beginning to think I sent my mail to the 
> wrong list. I've subscribed to freebsd-acpi@ now. For reference, the 
> issues (+patch) discussed are available at:
> 
> http://lists.freebsd.org/pipermail/freebsd-stable/2005-August/017535.html
> http://lists.freebsd.org/pipermail/freebsd-stable/2005-August/017536.html
> 
> > I have a P4m with ICHSS and P4TCC and I do hit both the problem of the
> > wrong mode being selected when there is a tie for performance level
> > and the case of lower performance resulting in higher power
> > consumption. You can see the results of my testing in messages to
> > freebsd-acpi@ archives. I have been wanting to write some patches to
> > fix the problems, but have simply not had time, so these patches look
> > great! 
> 
> In my experience throttling doesn't really gain that much. There's 
> almost no difference between running at 600MHz/100% and 600MHz/12.5%, 
> except that it is 8 times slower, so I've set debug.cpufreq.lowest to 
> 400 to limit the performance drop.

Odd. I don't see that at all. I am running at either 1.8 GHz or 1.2 GHz
and the performance ramps almost in lock-step with the setting and power
consumption does, as well. Without your patch, using the values of
dev.cpu.0.freq that run the CPU at the slower speed (1.2 GHz), I get the
following:
dev.cpu.0.freq	Temp.	Savings
1200		73
1050		69	 5.5%
 750		64	12.3%
 600		62	15.1%
 300		58	20.5%
 150		54	25.0%
The lowest 1.8 GHz value (1350) results in 85.I find these power
savings to be significant.

I test performance with:
dd bs=1m count=100 if=/dev/zero | md5

This should be totally CPU bound as the only I/O is from /dev/zero. I
report the number of bytes/second processed. I have a small perl script
that I use for this. (I will attach it.)

For power consumption I run the CPU at 100% until the CPU temperature
stabilizes. I realize that this is only an approximation of power
consumption, but I think it's close enough.

> I've also slightly modified powerd to not jump to the maximum frequency, 
> but to step up one level at a time to save energy. I've been thinking, 
> since throttling doesn't gain much, it might be better for powerd to 
> use only absolute settings when stepping up, but that would require an 
> extra sysctl entry (dev.cpu.0.freq_abs or something).

I have long espoused a different adaptive algorithm and use a "down by
1/up by 2" algorithm, myself. I wrote my own patch, but phk has posted
a cleaner one to current. See
http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-April/048877.html

> All this together with the patch above gives me a good desktop 
> experience. It's not too slow and it doesn't consume much power either. 
> Of course, other users might prefer different power profiles.

Very true, and the desired profile for a given user might well change
with a different situation (e.g. when on a long flight).

> > To take a stab at your questions:
> > First, if P4TCC is available, it should be used and CPU throttling
> > should be disabled. This is because P4TCC does better than CPU
> > throttle, but really does the exact same thing. The results of my
> > testing of P4TCC vs. throttling are also in the archives of
> > freebsd-acpi at .
> >
> > I have not seen any problem with this. Could you describe exactly
> > whet behavior you are seeing?
> 
> Currently, acpi_throttle (driver) doesn't attach when it finds p4tcc0 
> (device), but p4tcc (driver) always attaches even if acpi_throttle0 
> (device) is present. As I understand things, both do exactly the same 
> (but in a different way), so they shouldn't both be enabled at the same 
> time.

This is correct and is the designed behavior. TCC is a throttling system
that is internal to the CPU while throttling is externally
controlled. Testing shows that TCC works better than throttling. It's
more linear and provides better power reduction at a specified
performance level in most cases (never worse, but sometime equal).

> You can get in this situation by not loading cpufreq.ko through 
> loader.conf (so acpi_throttle attaches) and then kldload it later. If 
> p4tcc is prefered, I suppose it should find acpi_throttle0 and detach 
> it (or maybe acpi_throttle should become part of cpufreq.ko).

Ahh. I don't think that I have ever tried this.
> 
> > I am pretty sure that 'option CPU_TCC_ENABLE' is obsolete. It's gone
> > from V6 and current. I suspect that it was missed when the CPU power
> > management stuff was MFCed to V5. Please drop freebsd-acpi@ a note so
> > this can be fixed.
> 
> I've found references in the following files. There may be more of 
> course.
> 
> sys/conf/files.i386 (line 258)
> sys/conf/options.i386 (line 56)
> sys/i386/conf/NOTES (line 133 + line 215).
> sys/i386/i386/p4tcc.c (can be removed?)

I don't know if the merge from current should have included
these.

I can now confirm that the patch applied cleanly to -current and works
as advertised. I have only done performance testing at this time. Testing
for power consumption takes quite a bit longer and I have a day job
stuff that will prevent testing for a while.

Thanks again,
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634

-------------- next part --------------
#!/usr/bin/perl
$min_speed = 150;
($freq) = `sysctl dev.cpu.0.freq_levels`;
@freq = split ' ', $freq;
@freq = grep /\d+\/-?\d+/, @freq;
foreach (@freq) {s/^(\d+).+$/$1/;}
foreach (@freq) {
#  if ($_ < $min_speed) {next;}
  `sysctl dev.cpu.0.freq=$_`;
  `dd if=/dev/zero bs=1m count=100 2>/tmp/testresult |  md5`;
  @result = `cat /tmp/testresult`;
  $result = $result[2];
  $result =~ /secs \((\d+) bytes\/sec/;
  printf "%4d %s\n", $_, $1;
}
# Now do it backwards (speed up)
for ($i=$#freq; $i>=0; $i--) {
#  if ($freq[$i] < $min_speed) {next;}
  `sysctl dev.cpu.0.freq=$freq[$i]`;
  `dd if=/dev/zero bs=1m count=100 2>/tmp/testresult | md5`;
  @result = `cat /tmp/testresult`;
  $result = $result[2];
  $result =~ /secs \((\d+) bytes\/sec/;
  printf "%4d %s\n", $freq[$i], $1;
}
`sysctl dev.cpu.0.freq=1800`;
unlink "/tmp/testresult";
exit;