Re: Possible CPUFreq governor

[Mark Bidewell <mark.bidewell@alumni.clemson.edu>]

I have been examining the structure and design of the ondemand govenor 
further.  Would it be accurate to characterize your concern as basically 
that under heavy process load, the p-state switching latency becomes 
longer than the timeslices and thus could dominate the CPU?  Or is there 
an issue with processor damage?

Bruno Ducrot wrote:

>On Wed, Apr 27, 2005 at 02:18:27PM -0400, Mark Bidewell wrote:
>  
>
>>It might help to explain how the governor is used. I have a user-mode
>>daemon which samples the ACPI temperature every 2 seconds and communicates
>>the speed at which non-interactive processes should be run via the sysfs
>>interface.  The scheduler will then determine a processes interactivity
>>and change the CPU speed accordingly.  In theory the processor could
>>change speeds every process switch.
>>    
>>
>
>That why I have to do tests in case there is a lot of those process
>switch but when modifiying max frequency instead.
>
>  
>
>>This governor is indeed similar to the ondemand governor.  The distinction
>>is that while the ondemand governor expands CPU performance as load
>>increases, tempscale must limit performance.  In my opinion, the ultimate
>>solution would be a combination of the two governors.  That is, a governor
>>which would react in the following way:
>>
>>1)  If the processor is idle, run at low speeds to conserve power (ondemand).
>>2)  Increase performance with demand as long a temperature is low (ondemand)
>>3)  If temperatures get to high, throttle compute-bound processes (tempscale)
>>
>>I have done some limited experiments along this line using a user-mode
>>daemon to switch governors (as well as speeds) between tempscale and
>>ondemand as temperatures change.
>>    
>>
>
>That's why I suggest to touch max frequency, not the actual frequency.
>
>This must be done outside a governor, so that you can have both actually.
>I'll send you a patch after writing it for testing purpose so that you will
>see what I have in mind.
>
>  
>