From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
Intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 3/3] drm/i915: Export engine busy stats in debugfs
Date: Wed, 10 May 2017 09:30:15 +0100 [thread overview]
Message-ID: <e8564ce8-9804-cfaf-affa-2b06feb7ad91@linux.intel.com> (raw)
In-Reply-To: <2b684368-2da8-a24c-00e0-4a9aeadf63f3@intel.com>
On 09/05/2017 19:17, Dmitry Rogozhkin wrote:
> On 5/9/2017 7:09 AM, Tvrtko Ursulin wrote:
[snip]
>> +static ssize_t i915_engine_stats_read(struct file *file, char __user
>> *ubuf,
>> + size_t count, loff_t *pos)
>> +{
>> + struct i915_engine_stats_buf *buf =
>> + (struct i915_engine_stats_buf *)file->private_data;
>> +
>> + if (*pos == 0) {
>> + struct drm_i915_private *dev_priv = file->f_inode->i_private;
>> + char *ptr = &buf->buf[0];
>> + int left = buf->len;
>> + struct intel_engine_cs *engine;
>> + enum intel_engine_id id;
>> +
>> + buf->available = 0;
>> +
>> + for_each_engine(engine, dev_priv, id) {
>> + u64 total;
>> + int len;
>> +
>> + spin_lock_irq(&engine->stats.lock);
>> + total = engine->stats.total;
>> + /*
>> + * If the engine is executing something at the moment
>> + * add it to the total.
>> + */
>> + if (engine->stats.ref)
>> + total += ktime_get_real_ns() -
>> + engine->stats.start;
>> + spin_unlock_irq(&engine->stats.lock);
>> +
>> + len = snprintf(ptr, left, "%s: %llu\n",
>> + engine->name, total);
> If I caught it right, file format is:
> render ring: 12345
> bsd ring: 12345
> ...
Yes almost, just that the engine names have been changed to likes of
rcs0, vcs0, vcs1, vecs0 and bcs0 in the meantime.
> where numbers are busy clocks (ns) from the system boot time. Is that
Nanoseconds, but not since boot time but since the last time tracking
got enabled.
Because the most important thing in this version, from the point of view
of overhead in interrupt tasklet, is that the tracking is not done
unless somebody is listening (has the file open).
As I wrote in the cover letter and the 2nd patch, when nobody has the
file open the only thing which exists in the interrupt tasklets are
three no-nop instructions. They only get patched to jumps (to sections
actually collecting the stats) for as long as someone has the file open.
> right? What if we will want to expose some other statistics information
> later, not only busy clocks? For example, engines i915 queues depths is
> a next interest. Maybe later we will find something else interesting.
> So, do we want to consider this file to contain all kind of statistics
> in the future, and hence it should be of somewhat different format, or
> it will have only busy clocks, and maybe we need other file name then?
It can be either of the two, or some third option. It sounds like it is
too early to discuss those level of detail. At this point it was an RFC
only to gather some opinions on the overall idea.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-05-10 8:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-09 14:09 [RFC 0/3] Engine utilization tracking Tvrtko Ursulin
2017-05-09 14:09 ` [RFC 1/3] drm/i915: Wrap context schedule notification Tvrtko Ursulin
2017-05-09 14:09 ` [RFC 2/3] drm/i915: Engine busy time tracking Tvrtko Ursulin
2017-05-10 12:41 ` Joonas Lahtinen
2017-05-09 14:09 ` [RFC 3/3] drm/i915: Export engine busy stats in debugfs Tvrtko Ursulin
2017-05-09 18:17 ` Dmitry Rogozhkin
2017-05-10 8:30 ` Tvrtko Ursulin [this message]
2017-05-10 15:57 ` Dmitry Rogozhkin
2017-05-09 14:26 ` [RFC 0/3] Engine utilization tracking Chris Wilson
2017-05-09 15:16 ` Tvrtko Ursulin
2017-05-09 15:29 ` Chris Wilson
2017-05-09 15:51 ` Tvrtko Ursulin
2017-05-09 18:11 ` Dmitry Rogozhkin
2017-05-10 8:38 ` Tvrtko Ursulin
2017-05-10 15:50 ` Dmitry Rogozhkin
2017-05-10 19:45 ` Daniel Vetter
2017-05-12 17:40 ` Dmitry Rogozhkin
2017-05-10 12:31 ` Chris Wilson
2017-05-09 14:51 ` ✓ Fi.CI.BAT: success for " 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=e8564ce8-9804-cfaf-affa-2b06feb7ad91@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=dmitry.v.rogozhkin@intel.com \
--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.