[Skiboot] [PATCH] occ: Filter out entries from Pmin to Pmax in pstate table

[Balbir Singh]

>>
>> I was wondering if we just expose all the pstates including p_min and p_max and
>> nr_pstates, the OS might be better at filtering states and implementing the
>> right thing in the future without requiring a reboot (may be in the future).
>> We might be able to show turbo p-states and show them as disabled in the OS
> 
> Hi Balbir,
> 
> There are two scenarios of turbo mode control:
> (a) OS driven policy:
> 
> This is the case you are talking about where we would like Linux OS
> cpufreq driver to control the limits of cpu frequency scaling in order
> to drive responsiveness and efficiency for workloads.
> 
> We can do this today by setting the max scaling frequency limit in
> ondemand and performance governor and we can have tuned profiles to
> make this simple for end users.
> 
> We have the full cpu frequency range including exposed to cpu-freq
> driver and also the min/nominal/max frequency is available in sysfs to
> set the required policy.
> 
> We can disable turbo mode today by setting max scaling frequency to
> the current nominal frequency.
> 
> (b) Firmware driven policy:
> 
> This is the case Shilpa's fix addresses.  The goal here is to have an
> equivalent of BIOS based settings that is consistent across different
> OS instances and limits the policies that OS can use.
> 
> Turbo mode disable in scenario (a) can be done by setting cpu-freq
> driver limits.  However for case (b) we need to filter out the allowed
> range and tell Linux only the PStates that Linux will be allowed to
> set.
> 
> OCC will limit the range and today if the PState requested by Linux is
> not granted by OCC then we assume a power cap or throttle situation
> and do not expect to have a cpu freq policy conflict between OCC and
> Linux.
> 

Hi, Vaidy

I understand (a) and (b) and the patch looks good, however, I was just wondering
if keeping the future in mind lets consider the following p-states

p_min, p_1, p_2, ..., p_max

p_max will change based on settings by OCC

p_min, p_1, p_2, ..., current p_max, ..., tp_max

If OCC in the future were to ever make tp_max dynamic (change without reboot), the
current code would require a reboot, we could support it.
But I realize that this is beyond the scope of this patch.

The patch overall makes sense

Balbir Singh