patch: p4tcc and speedstep cpufreq drivers
Nate Lawson
nate at root.org
Fri Mar 4 18:14:32 GMT 2005
Kevin Oberman wrote:
>>Date: Thu, 03 Mar 2005 21:37:05 -0800
>>From: Nate Lawson <nate at root.org>
>>
>>Kevin Oberman wrote:
>>
>>>OK. This makes me feel a bit better, but I still think I'll leave TCC
>>>out of the equation as it makes the various frequency steps vary uneven
>>>to the point that lowering dev.cpu.0.freq would increase performance
>>>(and the reverse, as well) and it causes my system to hang when
>>>throttled back too far. It never hangs with TCC disabled although my
>>>lowest "frequency" is now just 150 MHz.
>>
>>Would you test with hint.acpi_throttle.0.disabled="1" instead of
>>disabling p4tcc? I think p4tcc is not the problem, it's the combination
>>of the two. I think there are some problems when both the chipset
>>(externally) and processor (internally) assert STOPCLOCK. If this works
>>for you with no hangs, I'll commit code to disable acpi_throttle when
>>p4tcc is present. p4tcc is more efficient than acpi_throttle since the
>>latter is done through the chipset, giving more chance for race
>>conditions, latency, etc.
>
> Looks like you are right on the button. p4tcc with throttling disabled
> yields the best results I have seen. The performance is just a
> little better than the "normalized" value I would expect where
> throttling produced performance just a little worse. As long as I don't
> run both, I don't hang at any speed and I don't get increased
> performance with decreased speed.
Ok, I'll commit my patch.
> I really want to try some tests while actively monitoring current draw
> some day, but it will require hacking on a power brick and I don't have
> one I can play with at the moment. That would provide some REAL
> indication of power savings with reduced performance and make tuning
> more accurate.
I have one we made for this purpose. Also fun on refrigerators.
--
Nate
More information about the freebsd-acpi
mailing list