All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness
Date: Wed, 24 Aug 2022 23:18:14 -0700	[thread overview]
Message-ID: <87mtbsyhg9.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20220615174208.GL48807@orsosgc001.jf.intel.com>

On Wed, 15 Jun 2022 10:42:08 -0700, Umesh Nerlige Ramappa wrote:
>
> >>>> +static void __guc_context_update_clks(struct intel_context *ce)
> >>>> +{
> >>>> +    struct intel_guc *guc = ce_to_guc(ce);
> >>>> +    struct intel_gt *gt = ce->engine->gt;
> >>>> +    u32 *pphwsp, last_switch, engine_id;
> >>>> +    u64 start_gt_clk = 0, active = 0;
> >>>
> >>> No need to init these two.
> >>>
> >>>> +    unsigned long flags;
> >>>> +    ktime_t unused;
> >>>> +
> >>>> +    spin_lock_irqsave(&guc->timestamp.lock, flags);
> >>>> +
> >>>> +    pphwsp = ((void *)ce->lrc_reg_state) - LRC_STATE_OFFSET;
> >>>> +    last_switch = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_STAMP_LO]);
> >>>> +    engine_id = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_ENGINE_ID]);
> >>>> +
> >>>> +    guc_update_pm_timestamp(guc, &unused);
> >>>> +
> >>>> +    if (engine_id != 0xffffffff && last_switch) {
> >>>> +        start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
> >>>> +        __extend_last_switch(guc, &start_gt_clk, last_switch);
> >>>> +        active = intel_gt_clock_interval_to_ns(gt,
> >>>> guc->timestamp.gt_stamp - start_gt_clk);
> >>>> +        WRITE_ONCE(ce->stats.runtime.start_gt_clk, start_gt_clk);
> >>>> +        WRITE_ONCE(ce->stats.active, active);
> >>>> +    } else {
> >>>> +        lrc_update_runtime(ce);
> >>>
> >>> Why is this called from here? Presumably it was called already from
> >>> guc_context_unpin if here code things context is not active. Or will be
> >>> called shortly, once context save is done.
> >>
> >> guc_context_unpin is only called in the path of ce->sched_disable. The
> >> sched_disable is implemented in GuC (H2G message). Once the
> >> corresponding G2H response is received, the context is actually
> >> unpinned, eventually calling guc_context_unpin. Also the context may not
> >> necessarily be disabled after each context exit.
> >
> > So if I understand correctly, lrc runtime is only updated if someone is
> > reading the busyness and not as part of normal context state transitions?
>
> If you mean context_in/out events (like csb interrupts), only GuC can see
> those events. KMD has no visibility into that. These 3 paths call
> lrc_update_runtime.
>
> user query: (engine_id != 0xffffffff && last_switch) translates to GuC
> being within context_in and context_out events, so updating it outside of
> this window is one way to report the correct busyness.
>
> worker: guc_timestamp_ping()  also updates context stats (infrequently) for
> all contexts primarily to take care of overflows.
>
> context unpin: Existing code calls lrc_update_runtime only when unpinning
> the context which takes care of accumulating busyness when requests are
> retired.

Will adding lrc_update_runtime() to lrc_unpin() work?

  reply	other threads:[~2022-08-25  7:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-14  0:46 [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness Nerlige Ramappa, Umesh
2022-06-14  2:23 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-06-14  2:23 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-06-14  2:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-06-14 13:30 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2022-06-14 16:32   ` Umesh Nerlige Ramappa
2022-06-15  7:08     ` Tvrtko Ursulin
2022-06-15 17:42       ` Umesh Nerlige Ramappa
2022-08-25  6:18         ` Dixit, Ashutosh [this message]
2022-06-15  0:29 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2022-06-16 19:08 [Intel-gfx] [PATCH] " Nerlige Ramappa, Umesh
2022-06-16 22:13 Nerlige Ramappa, Umesh
2022-06-17  8:00 ` Tvrtko Ursulin
2022-07-27  6:01   ` Umesh Nerlige Ramappa
2022-07-27  8:48     ` Tvrtko Ursulin
2022-08-01 19:02       ` Umesh Nerlige Ramappa
2022-08-02  8:41         ` Tvrtko Ursulin
2022-08-02 23:38           ` Umesh Nerlige Ramappa
2022-08-04  1:21             ` Umesh Nerlige Ramappa
2022-08-04  7:25               ` Tvrtko Ursulin
2022-08-04 23:21 Umesh Nerlige Ramappa
2022-08-05  9:45 ` Tvrtko Ursulin
2022-08-05 15:18   ` Umesh Nerlige Ramappa
     [not found]     ` <87fshl3yw0.wl-ashutosh.dixit@intel.com>
2022-08-26 15:44       ` Umesh Nerlige Ramappa
2022-08-25  5:03 ` Dixit, Ashutosh
2022-08-25 21:12   ` Dixit, Ashutosh
2022-08-26  1:44 ` Dixit, Ashutosh
2022-08-26 16:33   ` Umesh Nerlige Ramappa
2022-08-31 20:25     ` Dixit, Ashutosh
2022-08-31 22:57       ` Umesh Nerlige Ramappa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mtbsyhg9.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=umesh.nerlige.ramappa@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.