Re: [RFC] drm/i915: Add a new modparam for customized ring multiplier

From: Yaodong Li <yaodong.li@intel.com>
To: Sagar Arun Kamble <sagar.a.kamble@intel.com>,
	"Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "Widawsky, Benjamin" <benjamin.widawsky@intel.com>
Subject: Re: [RFC] drm/i915: Add a new modparam for customized ring multiplier
Date: Thu, 4 Jan 2018 13:52:12 -0800	[thread overview]
Message-ID: <f2546e73-443a-7786-e367-4a8d6b1b947a@intel.com> (raw)
In-Reply-To: <93e468ba-def8-7aad-92ef-4021e6a3d030@intel.com>


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??).

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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx