Re: patch: p4tcc and speedstep cpufreq drivers

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