Quoting Bloomfield, Jon (2019-08-29 16:44:41) > > -----Original Message----- > > From: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Sent: Thursday, August 29, 2019 1:12 AM > > To: intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>; Joonas Lahtinen > > <joonas.lahtinen@xxxxxxxxxxxxxxx>; Winiarski, Michal > > <michal.winiarski@xxxxxxxxx>; Bloomfield, Jon <jon.bloomfield@xxxxxxxxx> > > Subject: [PATCH 28/36] drm/i915: Cancel non-persistent contexts on close > > > > Normally, we rely on our hangcheck to prevent persistent batches from > > hogging the GPU. However, if the user disables hangcheck, this mechanism > > breaks down. Despite our insistence that this is unsafe, the users are > > equally insistent that they want to use endless batches and will disable > > the hangcheck mechanism. We are looking at perhaps replacing hangcheck > > with a softer mechanism, that sends a pulse down the engine to check if > > it is well. We can use the same preemptive pulse to flush an active > > persistent context off the GPU upon context close, preventing resources > > being lost and unkillable requests remaining on the GPU after process > > termination. To avoid changing the ABI and accidentally breaking > > existing userspace, we make the persistence of a context explicit and > > enable it by default (matching current ABI). Userspace can opt out of > > persistent mode (forcing requests to be cancelled when the context is > > closed by process termination or explicitly) by a context parameter. To > > facilitate existing use-cases of disabling hangcheck, if the modparam is > > disabled (i915.enable_hangcheck=0), we disable persistence mode by > > default. (Note, one of the outcomes for supporting endless mode will be > > the removal of hangchecking, at which point opting into persistent mode > > will be mandatory, or maybe the default perhaps controlled by cgroups.) > > > > Testcase: igt/gem_ctx_persistence > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > Cc: Michał Winiarski <michal.winiarski@xxxxxxxxx> > > Cc: Jon Bloomfield <jon.bloomfield@xxxxxxxxx> > > --- > Reviewed-by: Jon Bloomfield <jon.bloomfield@xxxxxxxxx> One thing I could do with for this is an ack from whomever is volunteered to add the userspace support :) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
