All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Goel, Akash" <akash.goel@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 14/17] drm/i915: Add stats for GuC log buffer flush interrupts
Date: Mon, 18 Jul 2016 12:33:35 +0100	[thread overview]
Message-ID: <578CBE8F.5030408@linux.intel.com> (raw)
In-Reply-To: <fcd07e05-f1ea-87af-59fa-f6f41dd88067@intel.com>


On 18/07/16 11:59, Goel, Akash wrote:
> On 7/18/2016 3:46 PM, Tvrtko Ursulin wrote:
>>
>> On 15/07/16 16:58, Goel, Akash wrote:
>>> On 7/15/2016 5:21 PM, Tvrtko Ursulin wrote:
>>>> On 10/07/16 14:41, akash.goel@intel.com wrote:
>>>>> From: Akash Goel <akash.goel@intel.com>
>>>>>
>>>>> GuC firmware sends an interrupt to flush the log buffer when it
>>>>> becomes half full. GuC firmware also tracks how many times the
>>>>> buffer overflowed.
>>>>> It would be useful to maintain a statistics of how many flush
>>>>> interrupts were received and for which type of log buffer,
>>>>> along with the overflow count of each buffer type.
>>>>> Augmented i915_log_info debugfs to report back these statistics.
>>>>>
>>>>> Signed-off-by: Akash Goel <akash.goel@intel.com>
>>>>> ---
>>>>>   drivers/gpu/drm/i915/i915_debugfs.c        | 26
>>>>> ++++++++++++++++++++++++++
>>>>>   drivers/gpu/drm/i915/i915_guc_submission.c |  8 ++++++++
>>>>>   drivers/gpu/drm/i915/i915_irq.c            |  1 +
>>>>>   drivers/gpu/drm/i915/intel_guc.h           |  6 ++++++
>>>>>   4 files changed, 41 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>>>>> b/drivers/gpu/drm/i915/i915_debugfs.c
>>>>> index 3c9c7f7..888a18a 100644
>>>>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>>>>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>>>>> @@ -2538,6 +2538,30 @@ static int i915_guc_load_status_info(struct
>>>>> seq_file *m, void *data)
>>>>>       return 0;
>>>>>   }
>>>>>
>>>>> +static void i915_guc_log_info(struct seq_file *m,
>>>>> +                 struct drm_i915_private *dev_priv)
>>>>> +{
>>>>> +    struct intel_guc *guc = &dev_priv->guc;
>>>>> +
>>>>> +    seq_printf(m, "\nGuC logging stats:\n");
>>>>> +
>>>>> +    seq_printf(m, "\tISR:   flush count %10u, overflow count %8u\n",
>>>>> +        guc->log.flush_count[GUC_ISR_LOG_BUFFER],
>>>>> +        guc->log.total_overflow_count[GUC_ISR_LOG_BUFFER]);
>>>>> +
>>>>> +    seq_printf(m, "\tDPC:   flush count %10u, overflow count %8u\n",
>>>>> +        guc->log.flush_count[GUC_DPC_LOG_BUFFER],
>>>>> +        guc->log.total_overflow_count[GUC_DPC_LOG_BUFFER]);
>>>>> +
>>>>> +    seq_printf(m, "\tCRASH: flush count %10u, overflow count %8u\n",
>>>>> +        guc->log.flush_count[GUC_CRASH_DUMP_LOG_BUFFER],
>>>>> +        guc->log.total_overflow_count[GUC_CRASH_DUMP_LOG_BUFFER]);
>>>>> +
>>>>> +    seq_printf(m, "\tTotal flush interrupt count: %u\n",
>>>>> +            guc->log.flush_interrupt_count);
>>>>> +
>>>>> +}
>>>>> +
>>>>>   static void i915_guc_client_info(struct seq_file *m,
>>>>>                    struct drm_i915_private *dev_priv,
>>>>>                    struct i915_guc_client *client)
>>>>> @@ -2611,6 +2635,8 @@ static int i915_guc_info(struct seq_file *m,
>>>>> void *data)
>>>>>       seq_printf(m, "\nGuC execbuf client @ %p:\n",
>>>>> guc.execbuf_client);
>>>>>       i915_guc_client_info(m, dev_priv, &client);
>>>>>
>>>>> +    i915_guc_log_info(m, dev_priv);
>>>>> +
>>>>>       /* Add more as required ... */
>>>>>
>>>>>       return 0;
>>>>> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
>>>>> b/drivers/gpu/drm/i915/i915_guc_submission.c
>>>>> index c1e637f..9c94a43 100644
>>>>> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
>>>>> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
>>>>> @@ -914,6 +914,14 @@ static void guc_read_update_log_buffer(struct
>>>>> drm_device *dev)
>>>>>           log_buffer_state_local = *log_buffer_state;
>>>>>           buffer_size = log_buffer_state_local.size;
>>>>>
>>>>> +        guc->log.flush_count[i] +=
>>>>> log_buffer_state_local.flush_to_file;
>>>>> +        if (log_buffer_state_local.buffer_full_cnt !=
>>>>> +                    guc->log.prev_overflow_count[i]) {
>>>>> +            guc->log.prev_overflow_count[i] =
>>>>> +                    log_buffer_state_local.buffer_full_cnt;
>>>>> +            guc->log.total_overflow_count[i]++;
>>>>
>>>> Is log_buffer_state_local.buffer_full_cnt guaranteed to be one here? Or
>>>> you would need to increase total_overflow_count by its value?
>>>>
>>>
>>> buffer_full_cnt will not remain as one. Its a 4 bit counter, will be
>>> incremented monotonically by GuC firmware on every new detection of
>>> overflow, so will increase from 0 to 15 & then wrap around.
>>> Hence have to use '!=' in the condition instead of '>'.
>>
>> But can it happen that it jumps by more than one between being sampled
>> here? In which case you would need to replace:
>>
>> guc->log.total_overflow_count[i]++;
>>
>> by something like:
>>
>>
>> guc->log.total_overflow_count[i] +=
>> log_buffer_state_local.buffer_full_cnt - guc->log.prev_overflow_count[i];
>>
>> (Doesn't handle the wrap though, just to illustrate my point.)
>>
> Actually logic in GuC firmware is such that overflow counter cannot
> increment by more than 1 without Driver coming into picture in between,
> by the virtue of flush interrupt.

Hm, and what happens to the data and overflow counter if the driver is 
not responsive enough?

> But nevertheless the logic on Driver side should be like the way you
> suggested.
>
> Does this revised logic looks fine ?
>
> if (log_buffer_state_local.buffer_full_cnt !=
>          guc->log.prev_overflow_count[i]) {
>      new_overflow = 1;
>      guc->log.total_overflow_count[i] +=
> (log_buffer_state_local.buffer_full_cnt - guc->log.prev_overflow_count[i]);
>
>      if (log_buffer_state_local.buffer_full_cnt <
> guc->log.prev_overflow_count[i])
>          guc->log.total_overflow_count[i] += 15;
>
>      log_buffer_state_local.buffer_full_cnt =
> guc->log.prev_overflow_count[i];
> }

Not sure, maybe += 16 ? If counter goes from 15 to zero, then -15, +15 = 
no change which is wrong?

But in general if the condition should not happen I would also put a 
WARN_ON_ONCE or a rate limited DRM_ERROR in that case.

Regards,

Tvrtko


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

  reply	other threads:[~2016-07-18 11:33 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-10 13:41 [PATCH v4 00/17] Support for sustained capturing of GuC firmware logs akash.goel
2016-07-10 13:41 ` [PATCH 01/17] drm/i915: Decouple GuC log setup from verbosity parameter akash.goel
2016-07-11  9:37   ` Tvrtko Ursulin
2016-07-11 11:41     ` Goel, Akash
2016-07-11 11:50       ` Tvrtko Ursulin
2016-07-11 12:11         ` Goel, Akash
2016-07-11 13:07           ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 02/17] drm/i915: Add GuC ukernel logging related fields to fw interface file akash.goel
2016-07-10 13:41 ` [PATCH 03/17] drm/i915: New structure to contain GuC logging related fields akash.goel
2016-07-10 13:41 ` [PATCH 04/17] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set akash.goel
2016-07-11 10:04   ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 05/17] drm/i915: Support for GuC interrupts akash.goel
2016-07-11 10:30   ` Tvrtko Ursulin
2016-07-11 13:15     ` Goel, Akash
2016-07-11 13:23       ` Tvrtko Ursulin
2016-07-11 13:38         ` Goel, Akash
2016-07-11 13:43           ` Tvrtko Ursulin
2016-07-11 14:20             ` Goel, Akash
2016-07-10 13:41 ` [PATCH 06/17] drm/i915: Handle log buffer flush interrupt event from GuC akash.goel
2016-07-19 10:58   ` Tvrtko Ursulin
2016-07-20  3:29     ` Goel, Akash
2016-07-10 13:41 ` [PATCH 07/17] drm/i915: Add a relay backed debugfs interface for capturing GuC logs akash.goel
2016-07-10 17:07   ` kbuild test robot
2016-07-19 11:31   ` Tvrtko Ursulin
2016-07-20  3:41     ` Goel, Akash
2016-07-10 13:41 ` [PATCH 08/17] drm/i915: Forcefully flush GuC log buffer on reset akash.goel
2016-07-19 11:12   ` Tvrtko Ursulin
2016-07-19 11:21     ` Chris Wilson
2016-07-20  4:21       ` Goel, Akash
2016-07-20  9:12         ` Chris Wilson
2016-07-20  9:48           ` Goel, Akash
2016-07-10 13:41 ` [PATCH 09/17] drm/i915: Debugfs support for GuC logging control akash.goel
2016-07-10 17:59   ` kbuild test robot
2016-07-19 11:24   ` Tvrtko Ursulin
2016-07-20  4:42     ` Goel, Akash
2016-07-20  9:08       ` Tvrtko Ursulin
2016-07-20  9:32         ` Goel, Akash
2016-07-20  9:47           ` Tvrtko Ursulin
2016-07-20 10:12             ` Goel, Akash
2016-07-20 10:40               ` Tvrtko Ursulin
2016-07-20 11:29                 ` Goel, Akash
2016-07-20 11:50                   ` Tvrtko Ursulin
2016-07-20 12:16                     ` Goel, Akash
2016-07-10 13:41 ` [PATCH 10/17] drm/i915: New module param to control the size of buffer used for storing GuC firmware logs akash.goel
2016-07-15 11:15   ` Tvrtko Ursulin
2016-07-15 15:36     ` Goel, Akash
2016-07-18 10:06       ` Tvrtko Ursulin
2016-07-18 12:19         ` Goel, Akash
2016-07-18 13:06           ` Tvrtko Ursulin
2016-07-18 13:40             ` Goel, Akash
2016-07-10 13:41 ` [PATCH 11/17] drm/i915: Support to create write combined type vmaps akash.goel
2016-07-15 11:31   ` Tvrtko Ursulin
2016-07-15 11:45     ` Chris Wilson
2016-07-15 16:30     ` Goel, Akash
2016-07-18 10:18       ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 12/17] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer akash.goel
2016-07-10 13:41 ` [PATCH 13/17] drm/i915: New lock to serialize the Host2GuC actions akash.goel
2016-07-15 11:40   ` Tvrtko Ursulin
2016-07-15 15:51     ` Goel, Akash
2016-07-18 10:12       ` Tvrtko Ursulin
2016-07-18 10:46         ` Goel, Akash
2016-07-18 11:18           ` Tvrtko Ursulin
2016-07-18 11:31             ` Goel, Akash
2016-07-18 11:36               ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 14/17] drm/i915: Add stats for GuC log buffer flush interrupts akash.goel
2016-07-15 11:51   ` Tvrtko Ursulin
2016-07-15 15:58     ` Goel, Akash
2016-07-18 10:16       ` Tvrtko Ursulin
2016-07-18 10:59         ` Goel, Akash
2016-07-18 11:33           ` Tvrtko Ursulin [this message]
2016-07-18 11:47             ` Goel, Akash
2016-07-10 13:41 ` [PATCH 15/17] drm/i915: Increase GuC log buffer size to reduce " akash.goel
2016-07-15 11:57   ` Tvrtko Ursulin
2016-07-15 14:42     ` Goel, Akash
2016-07-15 15:07       ` Tvrtko Ursulin
2016-07-15 16:20         ` Goel, Akash
2016-07-18  9:54           ` Tvrtko Ursulin
2016-07-18 12:35             ` Goel, Akash
2016-07-18 13:08               ` Tvrtko Ursulin
2016-07-10 13:41 ` [PATCH 16/17] drm/i915: Optimization to reduce the sampling time of GuC log buffer akash.goel
2016-07-10 13:41 ` [PATCH 17/17] drm/i915: Use rt priority kthread to do GuC log buffer sampling akash.goel
2016-07-20 19:34   ` Chris Wilson
2016-07-21  3:41     ` Goel, Akash
2016-07-21  5:43       ` Chris Wilson
2016-07-21  6:18         ` Goel, Akash
2016-07-21  9:44           ` Tvrtko Ursulin
2016-07-10 14:12 ` ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs (rev5) 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=578CBE8F.5030408@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=akash.goel@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.