Intel-GFX Archive on 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 v2 7/9] drm/i915/perf: Handle non-power-of-2 reports
Date: Fri, 17 Feb 2023 12:58:18 -0800	[thread overview]
Message-ID: <87edqof1qt.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20230217005850.2511422-8-umesh.nerlige.ramappa@intel.com>

On Thu, 16 Feb 2023 16:58:48 -0800, Umesh Nerlige Ramappa wrote:
>

Hi Umesh, couple of nits below.

> Some of the newer OA formats are not powers of 2. For those formats,
> adjust the hw_tail accordingly when checking for new reports.
>
> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 50 ++++++++++++++++++--------------
>  1 file changed, 28 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> index 9715b964aa1e..d3a1892c93be 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -542,6 +542,7 @@ static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream)
>	bool pollin;
>	u32 hw_tail;
>	u64 now;
> +	u32 partial_report_size;
>
>	/* We have to consider the (unlikely) possibility that read() errors
>	 * could result in an OA buffer reset which might reset the head and
> @@ -551,10 +552,16 @@ static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream)
>
>	hw_tail = stream->perf->ops.oa_hw_tail_read(stream);
>
> -	/* The tail pointer increases in 64 byte increments,
> -	 * not in report_size steps...
> +	/* The tail pointer increases in 64 byte increments, whereas report
> +	 * sizes need not be integral multiples or 64 or powers of 2.
s/or/of/ ---------------------------------------^

Also I think report sizes can only be multiples of 64, the ones we have
seen till now definitely are. Also the lower 6 bits of tail pointer are 0.

> +	 * Compute potentially partially landed report in the OA buffer
>	 */
> -	hw_tail &= ~(report_size - 1);
> +	partial_report_size = OA_TAKEN(hw_tail, stream->oa_buffer.tail);
> +	partial_report_size %= report_size;
> +
> +	/* Subtract partial amount off the tail */
> +	hw_tail = gtt_offset + ((hw_tail - partial_report_size) &
> +				(stream->oa_buffer.vma->size - 1));

Couple of questions here because OA_TAKEN uses OA_BUFFER_SIZE and the above
expression uses stream->oa_buffer.vma->size:

1. Is 'OA_BUFFER_SIZE == stream->oa_buffer.vma->size'? We seem to be using
   the two interchaneably in the code.
2. If yes, can we add an assert about this in alloc_oa_buffer?
3. Can the above expression be changed to:

	hw_tail = gtt_offset + OA_TAKEN(hw_tail, partial_report_size);

It would be good to use the same construct if possible. Maybe we can even
change OA_TAKEN to something like:

#define OA_TAKEN(tail, head)    ((tail - head) & (stream->oa_buffer.vma->size - 1))

>
>	now = ktime_get_mono_fast_ns();
>
> @@ -677,6 +684,8 @@ static int append_oa_sample(struct i915_perf_stream *stream,
>  {
>	int report_size = stream->oa_buffer.format->size;
>	struct drm_i915_perf_record_header header;
> +	int report_size_partial;
> +	u8 *oa_buf_end;
>
>	header.type = DRM_I915_PERF_RECORD_SAMPLE;
>	header.pad = 0;
> @@ -690,8 +699,21 @@ static int append_oa_sample(struct i915_perf_stream *stream,
>		return -EFAULT;
>	buf += sizeof(header);
>
> -	if (copy_to_user(buf, report, report_size))
> +	oa_buf_end = stream->oa_buffer.vaddr +
> +		     stream->oa_buffer.vma->size;
> +	report_size_partial = oa_buf_end - report;
> +
> +	if (report_size_partial < report_size) {
> +		if (copy_to_user(buf, report, report_size_partial))
> +			return -EFAULT;
> +		buf += report_size_partial;
> +
> +		if (copy_to_user(buf, stream->oa_buffer.vaddr,
> +				 report_size - report_size_partial))
> +			return -EFAULT;
> +	} else if (copy_to_user(buf, report, report_size)) {
>		return -EFAULT;
> +	}
>
>	(*offset) += header.size;
>
> @@ -759,8 +781,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream *stream,
>	 * all a power of two).
>	 */
>	if (drm_WARN_ONCE(&uncore->i915->drm,
> -			  head > OA_BUFFER_SIZE || head % report_size ||
> -			  tail > OA_BUFFER_SIZE || tail % report_size,
> +			  head > OA_BUFFER_SIZE ||
> +			  tail > OA_BUFFER_SIZE,

The comment above the if () also needs to be fixed.

Also, does it make sense to have 'head % 64 || tail % 64' checks above? As
I was saying above head and tail will be 64 byte aligned.

>			  "Inconsistent OA buffer pointers: head = %u, tail = %u\n",
>			  head, tail))
>		return -EIO;
> @@ -774,22 +796,6 @@ static int gen8_append_oa_reports(struct i915_perf_stream *stream,
>		u32 ctx_id;
>		u64 reason;
>
> -		/*
> -		 * All the report sizes factor neatly into the buffer
> -		 * size so we never expect to see a report split
> -		 * between the beginning and end of the buffer.
> -		 *
> -		 * Given the initial alignment check a misalignment
> -		 * here would imply a driver bug that would result
> -		 * in an overrun.
> -		 */
> -		if (drm_WARN_ON(&uncore->i915->drm,
> -				(OA_BUFFER_SIZE - head) < report_size)) {
> -			drm_err(&uncore->i915->drm,
> -				"Spurious OA head ptr: non-integral report offset\n");
> -			break;
> -		}
> -
>		/*
>		 * The reason field includes flags identifying what
>		 * triggered this specific report (mostly timer
> --
> 2.36.1
>

  reply	other threads:[~2023-02-17 21:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17  0:58 [Intel-gfx] [PATCH v2 0/9] Add OAM support for MTL Umesh Nerlige Ramappa
2023-02-17  0:58 ` [Intel-gfx] [PATCH v2 1/9] drm/i915/perf: Drop wakeref on GuC RC error Umesh Nerlige Ramappa
2023-02-17  0:58 ` [Intel-gfx] [PATCH v2 2/9] drm/i915/perf: Add helper to check supported OA engines Umesh Nerlige Ramappa
2023-02-17  0:58 ` [Intel-gfx] [PATCH v2 3/9] drm/i915/perf: Validate OA sseu config outside switch Umesh Nerlige Ramappa
2023-02-17  1:10   ` Dixit, Ashutosh
2023-02-17  0:58 ` [Intel-gfx] [PATCH v2 4/9] drm/i915/perf: Group engines into respective OA groups Umesh Nerlige Ramappa
2023-02-22 21:52   ` Dixit, Ashutosh
2023-02-24 17:30     ` Umesh Nerlige Ramappa
2023-02-17  0:58 ` [Intel-gfx] [PATCH v2 5/9] drm/i915/perf: Fail modprobe if i915_perf_init fails on OOM Umesh Nerlige Ramappa
2023-02-17  2:04   ` Dixit, Ashutosh
2023-02-17  9:55     ` Jani Nikula
2023-02-17  0:58 ` [Intel-gfx] [PATCH v2 6/9] drm/i915/perf: Parse 64bit report header formats correctly Umesh Nerlige Ramappa
2023-02-21 22:14   ` Dixit, Ashutosh
2023-02-17  0:58 ` [Intel-gfx] [PATCH v2 7/9] drm/i915/perf: Handle non-power-of-2 reports Umesh Nerlige Ramappa
2023-02-17 20:58   ` Dixit, Ashutosh [this message]
2023-02-18  0:05     ` Umesh Nerlige Ramappa
2023-02-18  1:57       ` Dixit, Ashutosh
2023-02-21 18:51         ` Dixit, Ashutosh
2023-02-24 19:12           ` Umesh Nerlige Ramappa
2023-02-17  0:58 ` [Intel-gfx] [PATCH v2 8/9] drm/i915/perf: Add engine class instance parameters to perf Umesh Nerlige Ramappa
2023-02-17 23:37   ` Umesh Nerlige Ramappa
2023-02-21 23:53   ` Dixit, Ashutosh
2023-02-22  0:10     ` Dixit, Ashutosh
2023-02-24 19:37     ` Umesh Nerlige Ramappa
2023-02-24 20:48       ` Dixit, Ashutosh
2023-02-17  0:58 ` [Intel-gfx] [PATCH v2 9/9] drm/i915/perf: Add support for OA media units Umesh Nerlige Ramappa
2023-02-17 23:37   ` Umesh Nerlige Ramappa
2023-02-23 20:05   ` Dixit, Ashutosh
2023-02-25  0:58     ` Umesh Nerlige Ramappa
2023-02-25  3:58       ` Dixit, Ashutosh
2023-02-17  1:35 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add OAM support for MTL (rev2) Patchwork
2023-02-17  1:55 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-02-17 16:09 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=87edqof1qt.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox