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 3/3] drm/i915/perf: add new open param to configure polling of OA buffer
Date: Sat, 21 Mar 2020 00:16:29 -0700	[thread overview]
Message-ID: <87zhcarxde.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20200319225203.29679-4-umesh.nerlige.ramappa@intel.com>

On Thu, 19 Mar 2020 15:52:03 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>
> This new parameter let's the application choose how often the OA
> buffer should be checked on the CPU side for data availability. Longer
> polling period tend to reduce CPU overhead if the application does not
> care about somewhat real time data collection.

/snip/

> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index db649d03ab52..c781b9f31b3c 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1980,6 +1980,19 @@ enum drm_i915_perf_property_id {
>	 */
>	DRM_I915_PERF_PROP_GLOBAL_SSEU,
>
> +	/**
> +	 * This optional parameter specifies the timer interval in nanoseconds
> +	 * at which the i915 driver will check the OA buffer for available data.
> +	 * Minimum allowed value is 100 microseconds. A default value is used by
> +	 * the driver if this parameter is not specified. Note that a large
> +	 * value may reduce cpu consumption during OA perf captures, but it
> +	 * would also potentially result in OA buffer overwrite as the captures
> +	 * reach end of the OA buffer.

I would like to change the wording here a bit because the wording above
seems to say that the /same/ timer period which reduces cpu consumption
will also potentially result in OA buffer overwrites. This is misleading
and not true. Instead we should say something like: "Note that larger timer
values will reduce cpu consumption during OA perf captures. However,
excessively large values would potentially result in OA buffer overwrites
as captures reach end of the OA buffer".

Maybe some guidance to selecting the value, say based on sampling rate and
OA buffer size, could also be added here but at the minimum we should fix
up the wording as indicated above before pushing. Otherwise:

Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>

> +	 *
> +	 * This property is available in perf revision 5.
> +	 */
> +	DRM_I915_PERF_PROP_POLL_OA_PERIOD,
> +
>	DRM_I915_PERF_PROP_MAX /* non-ABI */
>  };
>
> --
> 2.20.1
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-03-21  7:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-19 22:52 [Intel-gfx] [PATCH 0/3] drm/i915/perf: add OA interrupt support Umesh Nerlige Ramappa
2020-03-19 22:52 ` [Intel-gfx] [PATCH 1/3] drm/i915/perf: rework aging tail workaround Umesh Nerlige Ramappa
2020-03-21 23:26   ` Dixit, Ashutosh
2020-03-22  4:44     ` Dixit, Ashutosh
2020-03-22 19:47       ` Dixit, Ashutosh
2020-03-24  3:17       ` Umesh Nerlige Ramappa
2020-03-24  3:15     ` Umesh Nerlige Ramappa
2020-03-19 22:52 ` [Intel-gfx] [PATCH 2/3] drm/i915/perf: move pollin setup to non hw specific code Umesh Nerlige Ramappa
2020-03-19 22:52 ` [Intel-gfx] [PATCH 3/3] drm/i915/perf: add new open param to configure polling of OA buffer Umesh Nerlige Ramappa
2020-03-21  7:16   ` Dixit, Ashutosh [this message]
2020-03-19 23:40 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: add OA interrupt support (rev7) Patchwork
2020-03-19 23:43 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-03-20  0:04 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-24 18:54 [Intel-gfx] [PATCH 0/3] drm/i915/perf: add OA interrupt support Umesh Nerlige Ramappa
2020-03-24 18:54 ` [Intel-gfx] [PATCH 3/3] drm/i915/perf: add new open param to configure polling of OA buffer 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=87zhcarxde.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.