Quoting Tvrtko Ursulin (2018-01-12 10:30:26) > > > On 12/01/2018 09:51, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-01-12 09:40:40) > >> So submit side doesn't work in either case, unless I am missing > >> something. Would need the pair of port manipulation and context_in to be > >> atomic. > > > > Sure, there is a small window with the result that we either never turn > > off the stats, or turn them off one too early (and then recover if the > > my understanding of the underflow protection holds). The same problem as > > existed before the reconstruction, except now the window is much > > smaller. I'm not that scared by this (it should not explode, nor result > > in hopelessly wrong stats) so it can wait until stats enabling doesn't > > need to peek at execlists. I think you will need to postpone enabling > > until the next context-switch if we wanted to avoid the atomics; except > > that poses a problem with the igt expecting busy-start to be accurate. A > > dilemma for later. > > My analysis was partially incorrect, yes, there is underflow protection > already. > > But I don't see that there is a race window where we end up with > permanent 100% busyness before the reconstruction patch. Where do you > see that? > > The worst I see without the reconstruction is to miss the accounting of > the batch currently in progress when stats get enabled. Which is a much > less serious, totally ignorable event. One is observable via pmu, the other not. If we fail to turn off busy-stats accounting, nothing is lost except for a few wasted cycles. Except on the next pmu, it starts from the previous cs instead of the enabling -- but that is a problem that also exists with the second user. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
