All of lore.kernel.org
 help / color / mirror / Atom feed
From: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: igt-dev@lists.freedesktop.org, Intel-gfx@lists.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t 03/12] tools/intel_gpu_top: Restore user friendly error message
Date: Thu, 28 Sep 2023 14:31:54 -0700	[thread overview]
Message-ID: <ZRXwyu8fXevwFvSz@unerlige-ril> (raw)
In-Reply-To: <6a9b5529-6b41-a29b-3608-81be00934fbf@linux.intel.com>

On Thu, Sep 28, 2023 at 09:16:23AM +0100, Tvrtko Ursulin wrote:
>
>On 27/09/2023 21:13, Umesh Nerlige Ramappa wrote:
>>On Fri, Sep 22, 2023 at 02:44:28PM +0100, Tvrtko Ursulin wrote:
>>>From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>>We have a nice error message displayed when an user with insufficient
>>>permissions tries to run the tool, but that got lost while Meteorlake
>>>support was added. Bring it back in.
>>>
>>>Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>---
>>>tools/intel_gpu_top.c | 10 +++++++---
>>>1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>>diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
>>>index 87e9681e53b4..e01355f90458 100644
>>>--- a/tools/intel_gpu_top.c
>>>+++ b/tools/intel_gpu_top.c
>>>@@ -554,9 +554,11 @@ static int get_num_gts(uint64_t type)
>>>
>>>        close(fd);
>>>    }
>>>-    assert(!errno || errno == ENOENT);
>>>-    assert(cnt > 0);
>>>-    errno = 0;
>>>+
>>>+    if (!cnt)
>>>+        cnt = errno;
>>>+    else
>>>+        errno = 0;
>>
>>ENOENT is the only way this logic is checking for num_gts.
>>
>>In this case error is propagated only if cnt == 0. What if cnt=1 and 
>>we get an error (other than ENOENT)? Should we ignore that?
>
>If cnt >= 1 then at least one tile was found so the errno happened 
>while probing for further tiles. So on single tile parts it can be 
>ignored.

I am actually only referring to single tile parts. The for loop iterates 
over MAX_GTs (4), so I am expecting an ENOENT from a single tile part 
when cnt >= 1. Anything else is an error/failure that we should flag.

> On multi-tile parts it cannot really happen, or even if it happens 
>situation would simply be "why is only one tile showing". If we want to 
>cover this impossible/unlikely case then maybe like this:
>
>	if (!cnt || (errno && errno != ENOENT))
>		cnt = -errno;

If you agree to the above logic, then this condition should do the 
trick.

Regards,
Umesh
>
>>I had something like this in mind for the regression (and sorry this 
>>fell through the cracks)
>>
>>https://patchwork.freedesktop.org/patch/541406/?series=118973&rev=1
>
>Oh back in June!
>
>I think yours work too, in which case it's a matter of a style choice 
>with which one to go. I don't have a strong preference - above would 
>be a bit more compact, while I think it still succinctly expresses the 
>failure condition ("nothing found or unexpected error while probing 
>for remote tiles").
>
>Regards,
>
>Tvrtko
>
>>
>>Regards,
>>Umesh
>>
>>>
>>>    return cnt;
>>>}
>>>@@ -590,6 +592,8 @@ static int pmu_init(struct engines *engines)
>>>    engines->fd = -1;
>>>    engines->num_counters = 0;
>>>    engines->num_gts = get_num_gts(type);
>>>+    if (engines->num_gts <= 0)
>>>+        return -1;
>>>
>>>    engines->irq.config = I915_PMU_INTERRUPTS;
>>>    fd = _open_pmu(type, engines->num_counters, &engines->irq, 
>>>engines->fd);
>>>-- 
>>>2.39.2
>>>

WARNING: multiple messages have this Message-ID (diff)
From: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: igt-dev@lists.freedesktop.org, Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH i-g-t 03/12] tools/intel_gpu_top: Restore user friendly error message
Date: Thu, 28 Sep 2023 14:31:54 -0700	[thread overview]
Message-ID: <ZRXwyu8fXevwFvSz@unerlige-ril> (raw)
In-Reply-To: <6a9b5529-6b41-a29b-3608-81be00934fbf@linux.intel.com>

On Thu, Sep 28, 2023 at 09:16:23AM +0100, Tvrtko Ursulin wrote:
>
>On 27/09/2023 21:13, Umesh Nerlige Ramappa wrote:
>>On Fri, Sep 22, 2023 at 02:44:28PM +0100, Tvrtko Ursulin wrote:
>>>From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>>We have a nice error message displayed when an user with insufficient
>>>permissions tries to run the tool, but that got lost while Meteorlake
>>>support was added. Bring it back in.
>>>
>>>Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>---
>>>tools/intel_gpu_top.c | 10 +++++++---
>>>1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>>diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
>>>index 87e9681e53b4..e01355f90458 100644
>>>--- a/tools/intel_gpu_top.c
>>>+++ b/tools/intel_gpu_top.c
>>>@@ -554,9 +554,11 @@ static int get_num_gts(uint64_t type)
>>>
>>>        close(fd);
>>>    }
>>>-    assert(!errno || errno == ENOENT);
>>>-    assert(cnt > 0);
>>>-    errno = 0;
>>>+
>>>+    if (!cnt)
>>>+        cnt = errno;
>>>+    else
>>>+        errno = 0;
>>
>>ENOENT is the only way this logic is checking for num_gts.
>>
>>In this case error is propagated only if cnt == 0. What if cnt=1 and 
>>we get an error (other than ENOENT)? Should we ignore that?
>
>If cnt >= 1 then at least one tile was found so the errno happened 
>while probing for further tiles. So on single tile parts it can be 
>ignored.

I am actually only referring to single tile parts. The for loop iterates 
over MAX_GTs (4), so I am expecting an ENOENT from a single tile part 
when cnt >= 1. Anything else is an error/failure that we should flag.

> On multi-tile parts it cannot really happen, or even if it happens 
>situation would simply be "why is only one tile showing". If we want to 
>cover this impossible/unlikely case then maybe like this:
>
>	if (!cnt || (errno && errno != ENOENT))
>		cnt = -errno;

If you agree to the above logic, then this condition should do the 
trick.

Regards,
Umesh
>
>>I had something like this in mind for the regression (and sorry this 
>>fell through the cracks)
>>
>>https://patchwork.freedesktop.org/patch/541406/?series=118973&rev=1
>
>Oh back in June!
>
>I think yours work too, in which case it's a matter of a style choice 
>with which one to go. I don't have a strong preference - above would 
>be a bit more compact, while I think it still succinctly expresses the 
>failure condition ("nothing found or unexpected error while probing 
>for remote tiles").
>
>Regards,
>
>Tvrtko
>
>>
>>Regards,
>>Umesh
>>
>>>
>>>    return cnt;
>>>}
>>>@@ -590,6 +592,8 @@ static int pmu_init(struct engines *engines)
>>>    engines->fd = -1;
>>>    engines->num_counters = 0;
>>>    engines->num_gts = get_num_gts(type);
>>>+    if (engines->num_gts <= 0)
>>>+        return -1;
>>>
>>>    engines->irq.config = I915_PMU_INTERRUPTS;
>>>    fd = _open_pmu(type, engines->num_counters, &engines->irq, 
>>>engines->fd);
>>>-- 
>>>2.39.2
>>>

  reply	other threads:[~2023-09-28 21:31 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-22 13:44 [igt-dev] [PATCH i-g-t 00/12] fdinfo tests, intel_gpu_top memory support, etc Tvrtko Ursulin
2023-09-22 13:44 ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 01/12] tests/i915/drm_fdinfo: Stress test context close versus fdinfo reads Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 02/12] tests/i915/drm_fdinfo: Add some memory info tests Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-27 13:20   ` [igt-dev] [PATCH i-g-t v2 " Tvrtko Ursulin
2023-09-27 13:20     ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 03/12] tools/intel_gpu_top: Restore user friendly error message Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-27 20:13   ` [igt-dev] " Umesh Nerlige Ramappa
2023-09-27 20:13     ` [Intel-gfx] " Umesh Nerlige Ramappa
2023-09-28  8:16     ` [igt-dev] " Tvrtko Ursulin
2023-09-28  8:16       ` [Intel-gfx] " Tvrtko Ursulin
2023-09-28 21:31       ` Umesh Nerlige Ramappa [this message]
2023-09-28 21:31         ` Umesh Nerlige Ramappa
2023-09-29 11:11         ` [igt-dev] " Tvrtko Ursulin
2023-09-29 11:11           ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 04/12] tools/intel_gpu_top: Fix clients header width when no clients Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 05/12] tools/intel_gpu_top: Fix client layout on first sample period Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 06/12] tools/intel_gpu_top: Optimise interactive display a bit Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 07/12] lib/igt_drm_fdinfo: Copy over region map name on match Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 08/12] lib/igt_drm_clients: Fix client id type confusion Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 09/12] lib/igt_drm_clients: Allow passing in the memory region map Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 10/12] tools/intel_gpu_top: Fully wrap clients operations Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 11/12] tools/intel_gpu_top: Add per client memory info Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 13:44 ` [igt-dev] [PATCH i-g-t 12/12] tools/intel_gpu_top: Add ability to show memory region breakdown Tvrtko Ursulin
2023-09-22 13:44   ` [Intel-gfx] " Tvrtko Ursulin
2023-09-22 15:03 ` [igt-dev] ✓ Fi.CI.BAT: success for fdinfo tests, intel_gpu_top memory support, etc Patchwork
2023-09-22 15:56 ` [igt-dev] ✓ CI.xeBAT: " Patchwork
2023-09-23 15:28 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2023-09-27 14:15 ` [igt-dev] ✓ CI.xeBAT: success for fdinfo tests, intel_gpu_top memory support, etc (rev2) Patchwork
2023-09-27 14:23 ` [igt-dev] ✗ Fi.CI.BAT: failure " 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=ZRXwyu8fXevwFvSz@unerlige-ril \
    --to=umesh.nerlige.ramappa@intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=tvrtko.ursulin@intel.com \
    --cc=tvrtko.ursulin@linux.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.