On 07/02/2020 17:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-07 16:49:17)
On 07/02/2020 16:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-07 16:13:30)
static inline void
-__intel_context_stats_start(struct intel_context *ce, ktime_t now)
+__intel_context_stats_start(struct intel_context *ce,
+ struct intel_engine_cs *engine,
+ ktime_t now)
{
struct intel_context_stats *stats = &ce->stats;
-
- if (!stats->active) {
- stats->start = now;
- stats->active = true;
+ struct i915_gem_context *ctx;
+
+ if (stats->active)
+ return;
+
+ stats->start = now;
+ stats->active = true;
+
+ rcu_read_lock();
+ ctx = rcu_dereference(ce->gem_context);
+ if (ctx && ctx->client) {
I'd rather avoid having to dig into the GEM context down here next to
the HW.
First thought would be to keep the stats local on the intel_context and
for the client to chase collate them when the user reads the fd.
Hmm, didn't you structure it like so earlier? What made you change your
mind?
Yes, it's in the cover letter - we must not have disappearing
contributions - client can submit from one context for a bit, close it,
and oops usage history lost.
If only we had a mechanism for accumulating contributions from stale
engines and then from stale contests?
ce->drm_client? :)
Yeah that is equally icky for swimming upstream.
Ok, I have an idea for capturing the contributions at close rather than
having to do global accumulations at runtime.
It's certainly possible by accumulating over context runtimes when they
are closed and adding to active runtime at readout. I contemplated that
solution as well.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
