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.br...@intel.com>
> >
> >
