Quoting Chris Wilson (2020-01-06 11:21:26) > If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the > user batch or in our own preamble, the engine raises a > GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so > respond to a semaphore wait by yielding the timeslice (if we have > another process to yield to!) > > The only real complication is that the interrupt is only generated for > the start of the semaphore wait, and is asynchronous to our > process_csb() -- that is we may not have registered the timeslice before > we see the interrupt. To ensure we don't miss a potential semaphore > (e.g. selftests/live_timeslice_preempt) we mark the interrupt and apply > it to the next timeslice regardless of whether it was active at the > time. Sigh. Preempt-to-busy uses a semaphore so if we do have multiple contexts to slice amongst, we keep on switching as we charge the preempt-to-busy semaphore against the next. Left in a bit of dilemma, we can excuse the preempt-to-busy, but then we are liable to miss a genuine stall (e.g. live_timeslice_preempt). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
