Quoting Mika Kuoppala (2019-06-12 15:09:49)
> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes:
> >> > +int i915_active_acquire_preallocate_barrier(struct i915_active *ref,
> >> > + struct intel_engine_cs *engine)
> >> > +{
> >> > + struct drm_i915_private *i915 = engine->i915;
> >> > + unsigned long tmp;
> >> > + int err = 0;
> >> > +
> >> > + GEM_BUG_ON(!engine->mask);
> >> > + for_each_engine_masked(engine, i915, engine->mask, tmp) {
> >> > + struct intel_context *kctx = engine->kernel_context;
> >> > + struct active_node *node;
> >> > +
> >> > + node = kmem_cache_alloc(global.slab_cache, GFP_KERNEL);
> >> > + if (unlikely(!node)) {
> >> > + err = -ENOMEM;
> >> > + break;
> >> > + }
> >> > +
> >> > + i915_active_request_init(&node->base,
> >> > + (void *)engine, node_retire);
>
> In commit you promise that you will queue a request for kernel context.
> But in here, you seem to use (abuse!?) the active request to
> make a shadow of a request and use it to call the idle barriers.
So this is preallocate, because we have to reserve some memory when
pinning the context as we cannot allocate during unpinning (which can
happen inside the shrinker).
Then on context unpin, we attach this preallocated node onto a list on
the engine, all while keeping the context marked as still active.
Later on, when the engine is marked as idle we flush the barriers with a
context switch to the kernel, see switch_to_kernel_context() in
intel_engine_pm.c, and the i915_request_add_barriers().
The intention is that we also call i915_request_add_barriers() when
emitting the heartbeat requests (once we eliminate the struct_mutex
interposition) so that there is a regular idling pulse and contexts are
not pinned for an eternity.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
