All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	Intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 4/5] drm/i915: Expose per-engine client busyness
Date: Thu, 15 Feb 2018 15:13:47 +0000	[thread overview]
Message-ID: <4e32d681-01ca-7733-4284-97920fe3fa4f@linux.intel.com> (raw)
In-Reply-To: <151868787384.15373.10954570764140498627@mail.alporthouse.com>


On 15/02/2018 09:44, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-02-15 09:41:53)
>>
>> On 14/02/2018 19:17, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2018-02-14 18:50:34)
>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>
>>>> Expose per-client and per-engine busyness under the previously added sysfs
>>>> client root.
>>>>
>>>> The new files are one per-engine instance and located under the 'busy'
>>>> directory.
>>>>
>>>> Each contains a monotonically increasing nano-second resolution times each
>>>> client's jobs were executing on the GPU.
>>>>
>>>> $ cat /sys/class/drm/card0/clients/5/busy/rcs0
>>>> 32516602
>>>>
>>>> This data can serve as an interface to implement a top like utility for
>>>> GPU jobs. For instance I have prototyped a tool in IGT which produces
>>>> periodic output like:
>>>>
>>>> neverball[  6011]:  rcs0:  41.01%  bcs0:   0.00%  vcs0:   0.00%  vecs0:   0.00%
>>>>        Xorg[  5664]:  rcs0:  31.16%  bcs0:   0.00%  vcs0:   0.00%  vecs0:   0.00%
>>>>       xfwm4[  5727]:  rcs0:   0.00%  bcs0:   0.00%  vcs0:   0.00%  vecs0:   0.00%
>>>>
>>>> This tools can also be extended to use the i915 PMU and show overall engine
>>>> busyness, and engine loads using the queue depth metric.
>>>>
>>>> v2: Use intel_context_engine_get_busy_time.
>>>> v3: New directory structure.
>>>>
>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/i915_drv.h |  8 ++++
>>>>    drivers/gpu/drm/i915/i915_gem.c | 86 +++++++++++++++++++++++++++++++++++++++--
>>>>    2 files changed, 91 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>>>> index 372d13cb2472..d6b2883b42fe 100644
>>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>>> @@ -315,6 +315,12 @@ struct drm_i915_private;
>>>>    struct i915_mm_struct;
>>>>    struct i915_mmu_object;
>>>>    
>>>> +struct i915_engine_busy_attribute {
>>>> +       struct device_attribute attr;
>>>> +       struct drm_i915_file_private *file_priv;
>>>> +       struct intel_engine_cs *engine;
>>>> +};
>>>> +
>>>>    struct drm_i915_file_private {
>>>>           struct drm_i915_private *dev_priv;
>>>>           struct drm_file *file;
>>>> @@ -350,10 +356,12 @@ struct drm_i915_file_private {
>>>>           unsigned int client_pid;
>>>>           char *client_name;
>>>>           struct kobject *client_root;
>>>> +       struct kobject *busy_root;
>>>>    
>>>>           struct {
>>>>                   struct device_attribute pid;
>>>>                   struct device_attribute name;
>>>> +               struct i915_engine_busy_attribute busy[I915_NUM_ENGINES];
>>>>           } attr;
>>>>    };
>>>>    
>>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>>>> index 46ac7b3ca348..01298d924524 100644
>>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>>> @@ -5631,6 +5631,45 @@ show_client_pid(struct device *kdev, struct device_attribute *attr, char *buf)
>>>>           return snprintf(buf, PAGE_SIZE, "%u", file_priv->client_pid);
>>>>    }
>>>>    
>>>> +struct busy_ctx {
>>>> +       struct intel_engine_cs *engine;
>>>> +       u64 total;
>>>> +};
>>>> +
>>>> +static int busy_add(int _id, void *p, void *data)
>>>> +{
>>>> +       struct i915_gem_context *ctx = p;
>>>> +       struct busy_ctx *bc = data;
>>>> +
>>>> +       bc->total +=
>>>> +               ktime_to_ns(intel_context_engine_get_busy_time(ctx,
>>>> +                                                              bc->engine));
>>>> +
>>>> +       return 0;
>>>> +}
>>>> +
>>>> +static ssize_t
>>>> +show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf)
>>>> +{
>>>> +       struct i915_engine_busy_attribute *i915_attr =
>>>> +               container_of(attr, typeof(*i915_attr), attr);
>>>> +       struct drm_i915_file_private *file_priv = i915_attr->file_priv;
>>>> +       struct intel_engine_cs *engine = i915_attr->engine;
>>>> +       struct drm_i915_private *i915 = engine->i915;
>>>> +       struct busy_ctx bc = { .engine = engine };
>>>> +       int ret;
>>>> +
>>>> +       ret = i915_mutex_lock_interruptible(&i915->drm);
>>>> +       if (ret)
>>>> +               return ret;
>>>> +
>>>
>>> Doesn't need struct_mutex, just rcu_read_lock() will suffice.
>>>
>>> Neither the context nor idr will be freed too soon, and the data is
>>> involatile when the context is unreffed (and contexts don't have the
>>> nasty zombie/undead status of requests). So the busy-time will be
>>> stable.
>>
>> Are you sure? What holds a reference to contexts while userspace might
>> by in sysfs reading the stat? It would be super nice if we could avoid
>> struct mutex here.. I just don't understand at the moment why it would
>> be safe.
> 
> RCU keeps the pointer alive, and in this case the context is not reused
> before being freed (unlike requests). So given that it's unref, it is
> dead and the stats will be stable, just not yet freed.

Somehow I missed the suggestion to replace with rcu_read_lock. Cool, 
this is then even more light-weight than I imagined.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-02-15 15:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14 18:50 [RFC 0/5] Per-client engine stats Tvrtko Ursulin
2018-02-14 18:50 ` [RFC 1/5] drm/i915: Track per-context engine busyness Tvrtko Ursulin
2018-02-14 19:07   ` Chris Wilson
2018-02-15  9:29     ` Tvrtko Ursulin
2018-02-15  9:35       ` Chris Wilson
2018-02-14 18:50 ` [RFC 2/5] drm/i915: Expose list of clients in sysfs Tvrtko Ursulin
2018-02-14 19:13   ` Chris Wilson
2018-02-15  9:35     ` Tvrtko Ursulin
2018-02-14 18:50 ` [RFC 3/5] drm/i915: Update client name on context create Tvrtko Ursulin
2018-02-14 18:50 ` [RFC 4/5] drm/i915: Expose per-engine client busyness Tvrtko Ursulin
2018-02-14 19:17   ` Chris Wilson
2018-02-15  9:41     ` Tvrtko Ursulin
2018-02-15  9:44       ` Chris Wilson
2018-02-15 15:13         ` Tvrtko Ursulin [this message]
2018-02-14 18:50 ` [RFC 5/5] drm/i915: Add sysfs toggle to enable per-client engine stats Tvrtko Ursulin
2018-02-14 18:55 ` ✗ Fi.CI.CHECKPATCH: warning for Per-client " Patchwork
2018-02-14 19:11 ` ✓ Fi.CI.BAT: success " Patchwork
2018-02-14 19:20 ` [RFC 0/5] " Chris Wilson
2018-02-15  9:44   ` Tvrtko Ursulin
2018-02-15  9:47     ` Chris Wilson
2018-02-15 10:50       ` Tvrtko Ursulin
2018-02-15  2:19 ` ✓ Fi.CI.IGT: success for " Patchwork
2019-10-25 14:21 [RFC 0/5] Per client engine busyness (all aboard the sysfs train!) Tvrtko Ursulin
2019-10-25 14:21 ` [RFC 4/5] drm/i915: Expose per-engine client busyness Tvrtko Ursulin
2019-10-25 14:42   ` Chris Wilson

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=4e32d681-01ca-7733-4284-97920fe3fa4f@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=tursulin@ursulin.net \
    /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.