public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>,
	"Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC PATCH 2/2] Fix per client busyness locking
Date: Wed, 7 Sep 2022 08:28:48 +0100	[thread overview]
Message-ID: <c0c9f2ab-315e-8589-50ff-bbf6d4c39de3@linux.intel.com> (raw)
In-Reply-To: <YxeRe5W0Zf/TBGWw@unerlige-ril>



On 06/09/2022 19:29, Umesh Nerlige Ramappa wrote:
> On Thu, Sep 01, 2022 at 04:55:22PM -0700, Dixit, Ashutosh wrote:
>> On Wed, 31 Aug 2022 15:45:49 -0700, Umesh Nerlige Ramappa wrote:

[snip]

>>> >
>>> >    intel_gt_reset_unlock(gt, srcu);
>>> >
>>> > @@ -1476,17 +1476,21 @@ void intel_guc_busyness_unpark(struct 
>>> intel_gt *gt)
>>> >             guc->timestamp.ping_delay);
>>> > }
>>> >
>>> > -static void __guc_context_update_clks(struct intel_context *ce)
>>> > +static u64 guc_context_update_stats(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, active;
>>> >    unsigned long flags;
>>> > +    u64 total, active = 0;
>>> >    ktime_t unused;
>>> >
>>> > +    intel_context_pin(ce);
>>>
>>> intel_context_pin can sleep and we are not allowed to sleep in this 
>>> path -
>>> intel_context_get_total_runtime_ns(), however we can sleep in the ping
>>> worker path, so ideally we want to separate it out for the 2 paths.
>>
>> Do we know which intel_context_get_total_runtime_ns() call is not allowed
>> to sleep? E.g. the code path from i915_drm_client_fdinfo() is allowed to
>> sleep. As mentioned I have done this is v2 of RFC patch which I think is
>> sufficient, but a more complicated scheme (which I think we can avoid for
>> now) would be to pin in code paths when sleeping is allowed.
>>
> 
> Hmm, maybe intel_context_get_total_runtime_ns can sleep, not sure why I 
> was assuming that this falls in the perf_pmu path. This is now in the 
> drm_fdinfo query path. + Tvrtko.
> 
> @Tvrtko, any idea if intel_context_get_total_runtime_ns path can sleep?

Not at the moment - it calls it from a lockless (rcu) section when 
walking all the contexts belonging to a client. Idea being performance 
queries should have minimum effect on a running system. I think it would 
be possible to change in theory but not sure how much work. There is a 
hard need to sleep in there or what?

Regards,

Tvrtko

  parent reply	other threads:[~2022-09-07  7:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-31 19:33 [Intel-gfx] [PATCH 1/2] i915/pmu: Wire GuC backend to per-client busyness Ashutosh Dixit
2022-08-31 19:33 ` [Intel-gfx] [RFC PATCH 2/2] Fix per client busyness locking Ashutosh Dixit
2022-08-31 22:45   ` Umesh Nerlige Ramappa
2022-09-01 23:55     ` Dixit, Ashutosh
2022-09-06 18:29       ` Umesh Nerlige Ramappa
2022-09-07  7:26         ` Dixit, Ashutosh
2022-09-07  7:28         ` Tvrtko Ursulin [this message]
2022-09-07 15:03           ` Dixit, Ashutosh
2022-09-08  9:33             ` Tvrtko Ursulin
2022-08-31 19:50 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] i915/pmu: Wire GuC backend to per-client busyness Patchwork

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=c0c9f2ab-315e-8589-50ff-bbf6d4c39de3@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox