[Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

[Sagar Arun Kamble]

On 1/5/2018 3:22 AM, Yaodong Li wrote:
>
> On 01/03/2018 10:10 PM, Sagar Arun Kamble wrote:
>> Since ring frequency programming needs consideration of both IA and 
>> GT frequency requests I think keeping the logic
>> to program the ring frequency table in driver that monitors both 
>> IA/GT busyness and power budgets like intel_ips
>> will be more appropriate. intel_ips is relying on global load derived 
>> from all CPUs.
>> I understand that power awareness and busyness based policy might be 
>> trickier but having that as tunable will give better flexibility.
>>
> By just looking into the current code, the way intel_ips checks gpu 
> busyness cannot reflect the actual workload of GT
> (e.g. gpu busy is true even if there's only one pending request), in 
> this case, we shall not increase the ring freq if we
> want to use a "workload monitoring" based solution. so we need a more 
> accurate way to monitor the current GT workload
> (e.g.  when the pending request count reaches a center tunable 
> threshold??).
Yes. May be we can share the PMU data about engine busyness with intel_ips.
>
>> On 1/3/2018 11:51 PM, Yaodong Li wrote:
>>>
>>>>>> You are thinking of plugging into intel_pstate to make it smarter 
>>>>>> for ia freq transitions?
>>>> Yep. This seems a correct step to give some automatic support 
>>>> instead of parameter/hardcoded multiplier.
>>>>
>>> Does this mean we should use cpufreq/intel_pstate based approach 
>>> instead of the current modparam solution for Gen9?
>>>
>>> Some concerns and questions about intel_pstate approach:
>>> a) Currently, we cannot get the accurate pstate/target freq value 
>>> from cpufreq in intel_pstate active mode since
>>>      these values won't be exported to cpufreq layer, so if we won't 
>>> change intel_pstate code then we only can get
>>>      the max cpu freq of a new policy.
>>> b) intel_pstate policy is attached to each logic cpu, which means we 
>>> will receive policy/freq transition notification
>>>     for each logic cpu freq change. One question is how we are going 
>>> to decide the freq of the ring? just use the max
>>>     cpu freq reported?
>>> c) With the intel_pstate approach we may still run into thermal 
>>> throttling, in this case, can a certain cooling device
>>>     be triggered to lower the cpu freq?
>>>
>>> Thanks and Regards,
>>> -Jackie
>>>
>>
>