[Intel-gfx] [Intel-gfx 2/2] drm/i915/guc: Add delay to disable scheduling after pin count goes to zero

[Teres Alexis, Alan Previn]

Shall fix all of the cosmetics and repost.

WRT the magic number 34 milisecs: It was to have a "1 milisec buffer over a 33-fps" type workload which was how the
issue was found in the first place (it was a workload that had hundreds of these 33-fps contexts running and thats why
the impact was great). I can add that reasoning next to the #define. However, i doubt any kind of metrics measurement
based choice can ever perfectly justify one value over another since the impact/improvement would always depend on the
type of workload and latency requirement of that workload.

WRT traces on intel_context_close - apologies that was a mistake - i realize i captured that from downstream reviews but
was never mentioned upstream and i actually had missed that fix from upstream series posting since the start. Eventhough
u said it doesn look plausible, I will just remove it on the next post since its a UAPI thing and rather not delay this
series on account of a UAPI change. We can do that if needed later.

WRT the threshold calculation (the 3/4 of remaining guc-ids), yes will fix the floating pt error and change to macro.

Thanks for catching this - will fix.
	> +static int guc_sched_disable_gucid_threshold_get(void *data, u64 *val)
	> +{
	> +     struct intel_guc *guc = data;
	> +
	Why no check on submission_is_used here?


...alan

On Mon, 2022-08-15 at 16:57 -0700, Harrison, John C wrote:
> On 8/15/2022 09:01, Alan Previn wrote:
> > From: Matthew Brost <matthew.brost at intel.com>
> > 
> >