Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > Quoting Mika Kuoppala (2019-08-12 10:39:01) >> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: >> >> > When testing whether we prevent suppressing preemption, it helps to >> > avoid a time slice expiring prematurely. >> > >> >> I did look the test and it does call schedule on it's own. >> >> So what we want to do is to postpone the defacto schedule tick >> provided by driver not to mess our own schedule? (which we >> use to check that no preemption does occur with equal >> priorities?) > > The test is trying to look at our mechanics to ensure that we don't > cause preemptions where we simply put back the same request. As such, we > have a marker in the preemption code that we are trying to avoid, and > must control the scheduling to exclude all other events than the one we > are injecting. > > The timeslice could expire and reverse A,B (to B,A) such that our > promotion of A does (correctly) cause a preemption that we expect never > to need. If there will be more users, then we can consider disable|enable_reschedule_timer or similar. Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
