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
>
next prev parent 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 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.