On 14/02/2018 19:07, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-02-14 18:50:31)
+ktime_t intel_context_engine_get_busy_time(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+ struct intel_context *ce = &ctx->engine[engine->id];
+ ktime_t total;
+
+ spin_lock_irq(&ce->stats.lock);
+
+ total = ce->stats.total;
+
+ if (ce->stats.active)
+ total = ktime_add(total,
+ ktime_sub(ktime_get(), ce->stats.start));
+
+ spin_unlock_irq(&ce->stats.lock);
Looks like we can just use a seqlock here.
Hm, you may have suggested this before? Even for whole engine stats.
I think it could yes, with the benefit of not delaying writers (execlist
processing) in presence of readers. But since the code is so writer
heavy, and readers so infrequent and light weight, I wouldn't think we
are in any danger of writer starvation, or even injecting any relevant
latencies into command submission.
Also, could we get into reader live-lock situations under heavy
interrupts? Probably not, since the reader section is again so light
weight compared to the rest code would have to do to trigger it.
I can try it and see what happens.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
