Quoting Chris Wilson (2020-04-15 12:24:59) > 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. [ 98.882025] bcs0: DOWN interrupt not recorded for idle, pm_iir:10, pm_isr:0, prev_down:0, down_threshold:3840, down_ei:5dc0 ISR doesn't seem helpful on first try. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
