Quoting Andi Shyti (2020-04-15 11:56:59) > Hi Chris, > > On Tue, Apr 14, 2020 at 05:14:22PM +0100, Chris Wilson wrote: > > By the time we respond to the RPS interrupt [inside a worker], the GPU > > may be running a different workload. As we look to make the evalution > > intervals shorter, these spikes are more likely to okay. Let's try to > > smooth over the spikes in the workload by comparing the EI interrupt > > [up/down events] with the most recently completed EI; if both say up, > > then increase the clocks, if they disagree stay the same. In principle, > > this means we now take 2 up EI to go increase into the next bin, and > > similary 2 down EI to decrease. However, if the worker runs fast enough, > > the previous EI in the registers will be the same as triggered the > > interrupt, so responsiveness remains unaffect. [Under the current scheme > > where EI are on the order of 10ms, it is likely that this is true and we > > compare the interrupt with the EI that caused it.] > > looks reasonable to me. Wouldn't it make also sense to evaluate > the difference between the current and the previous pm_iir? I was considering it... We can't look at IIR since we apply the mask, but ISR should be valid. Worth a looksee. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
