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

[Yaodong Li]

On 01/05/2018 02:15 AM, Sagar Arun Kamble wrote:
>
>
> 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.
Thank you Sagar! Can you tell more about how we can get the gpu busyness 
from PMU data?

I think the solution would be to set the ring freq table to use a ring 
freq >= current ia freq (for all possible gpu freq) once we found
gpu workload is high (need to tune the threshold), and we will decrease 
the ring freq (use a 2x multiplier?) once we found the GT
workload is low. The benefit to use the intel_ips is it can tell both 
the cpu & gpu busyness. However, we do need an accurate way
to check at least the busyness of gpu for this issue.

>>> 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
>>>>
>>>
>>
>