Quoting Tvrtko Ursulin (2018-04-09 12:43:50) > > On 09/04/2018 11:51, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-04-09 11:40:08) > >> > >> On 09/04/2018 11:27, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2018-04-09 11:17:04) > >>>> > >>>> On 09/04/2018 10:25, Chris Wilson wrote: > >>>>> Downside being that we either then use atomic64 throughout or we mix > >>>>> atomic32/atomic64 knowing that we're on x86. (I feel like someone else > >>>>> must have solved this problem in a much neater way, before they went to > >>>>> per-cpu stats ;) > >>>> > >>>> Is the winky implying you know who and where? :) We have three potential > >>>> solutions now, even for if the winky is suggesting something. > >>> > >>> Nah, just that atomic/locked counters are so old hat. Not sure if there > >>> remain any good examples for hotpath counters that remain applicable to > >>> our code. > >> > >> Leave it as is then for now and improve if we discover it is not good > >> enough? > > > > I did have an ulterior motive in that the cmpxchg did resolve one issue > > that irked me with the two counters being updated out of sync. Minor, > > minor glitches :) > > > > I don't have a strong preference either way. These instructions on the > > submit are not likely to stand out, as compared to the biggest fish of > > ksoftirqd, execlists_schedule() and execlists_dequeue(). > > I could move the queued decrement from submit_notify to backends, right > next to runnable++? Then both would be under the engine->timeline->lock > so any inconsistencies in readout I'd hope should be dismissable?
Fair. I have this itch to add a request->state, switch (request->state) { case QUEUED: stats->queued--; switch (now) { case QUEUED: BUG(); case: READY: stats->runnable++; case EXEC: break; } break; case ... } request->state = now; Stop me. Please, stop me. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx