From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 1/7] drm/i915/pmu: Change bitmask of enabled events to u32
Date: Wed, 17 May 2023 09:25:03 -0700 [thread overview]
Message-ID: <87ednf3oyo.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <0a1babb7-80cf-cfe7-4746-37b76934175a@linux.intel.com>
On Wed, 17 May 2023 01:26:15 -0700, Tvrtko Ursulin wrote:
>
>
> On 17/05/2023 07:55, Umesh Nerlige Ramappa wrote:
> > On Tue, May 16, 2023 at 05:25:50PM -0700, Dixit, Ashutosh wrote:
> >> On Tue, 16 May 2023 16:35:28 -0700, Umesh Nerlige Ramappa wrote:
> >>>
> >>
> >> Hi Umesh/Tvrtko,
> >>
> >> Mostly repeating comments/questions made on the previous patch below.
>
> First of all thanks for improving this, my v1 obviously wasn't good enough.
>
> >>
> >>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>
> >>> Having it as u64 was a confusing (but harmless) mistake.
> >>>
> >>> Also add some asserts to make sure the internal field does not overflow
> >>> in the future.
> >>>
> >>> v2: Fix WARN_ON firing for INTERRUPT event (Umesh)
> >>>
> >>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
> >>> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/i915_pmu.c | 26 ++++++++++++++++++--------
> >>> 1 file changed, 18 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> >>> b/drivers/gpu/drm/i915/i915_pmu.c
> >>> index 7ece883a7d95..96543dce2db1 100644
> >>> --- a/drivers/gpu/drm/i915/i915_pmu.c
> >>> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> >>> @@ -50,7 +50,7 @@ static u8 engine_event_instance(struct perf_event
> >>> *event)
> >>> return (event->attr.config >> I915_PMU_SAMPLE_BITS) & 0xff;
> >>> }
> >>>
> >>> -static bool is_engine_config(u64 config)
> >>> +static bool is_engine_config(const u64 config)
> >>> {
> >>> return config < __I915_PMU_OTHER(0);
> >>> }
> >>> @@ -88,9 +88,20 @@ static unsigned int config_bit(const u64 config)
> >>> return other_bit(config);
> >>> }
> >>>
> >>> -static u64 config_mask(u64 config)
> >>> +static u32 config_mask(const u64 config)
> >>> {
> >>> - return BIT_ULL(config_bit(config));
> >>> + unsigned int bit = config_bit(config);
> >>
> >> Give that config_bit() can return -1 (I understand it is avoided in
> >> moving
> >> the code to config_mask from config_bit), maybe the code below should
> >> also
> >> have that check?
> >
> > config_mask is only called to check frequency related events in the code,
> > so I don't see it returing -1 here.
>
> Yeah that should be fine since -1 would make the below asserts fire
> anyway. (If it would get called from a different path in the future.)
>
> >>
> >> int bit = config_bit(config);
> >>
> >> if (bit != -1)
> >> {
> >> ...
> >> }
> >>
> >> Though as mentioned below the 'if (__builtin_constant_p())' would have to
> >> go. Maybe the code could even have stayed in config_bit with the check.
> >>
> >>> +
> >>> + if (__builtin_constant_p(config))
> >>> + BUILD_BUG_ON(bit >
> >>> + BITS_PER_TYPE(typeof_member(struct i915_pmu,
> >>> + enable)) - 1);
> >>
> >> Given that config comes from the event (it is event->attr.config), can
> >> this
> >> ever be a builtin constant?
> >
> > Not sure about earlier code where these checks were inside config_bit(),
> > but with changes I made, I don't see this being a builtin
> > constant. However, nothing prevents a caller from just passing a
> > builtin_constant to this in future.
>
> Are you sure? I would have thought it would always be a compile time
> constant now that the check is in config_mask. Aahhh.. with the multi-tile
> changes maybe it can't unroll the loops and calculate the masks at compile
> time. Maybe it is a bit too much and we should drop the
> __builtin_constant_p branch? Probably..
Ah yes, with the code move to config_mask, they really all are compile time
constants (provided compiler can unroll the loops) so at least that is the
justfication for leaving the __builtin_constant_p in. So I'd probably just
leave it as is (though it is a bit too much).
> But I guess it is safe to use GEM_WARN_ON_ONCE instead of WARN_ON_ONCE
> since there are no external callers (nothing coming from event) now. That
> way at least production builds don't have to have the check.
Hmm, there's a GEM_WARN_ON but no GEM_WARN_ON_ONCE. So leave that as is too
I guess.
So I'm ok with the code staying as is. Enough bike-shed on this already.
Thanks.
--
Ashutosh
>
> Regards,
>
> Tvrtko
>
> >
> > Thanks,
> > Umesh
> >
> >>
> >>> + else
> >>> + WARN_ON_ONCE(bit >
> >>> + BITS_PER_TYPE(typeof_member(struct i915_pmu,
> >>> + enable)) - 1);
> >>
> >> There is really an even stricter limit on what the bit can be, which is
> >> the
> >> total number of possible events but anyway this is good enough.
> >>
> >> After addressing the above, this patch is:
> >>
> >> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> >>
> >>> +
> >>> + return BIT(config_bit(config));
> >>> }
> >>>
> >>> static bool is_engine_event(struct perf_event *event)
> >>> @@ -633,11 +644,10 @@ static void i915_pmu_enable(struct perf_event
> >>> *event)
> >>> {
> >>> struct drm_i915_private *i915 =
> >>> container_of(event->pmu, typeof(*i915), pmu.base);
> >>> + const unsigned int bit = event_bit(event);
> >>> struct i915_pmu *pmu = &i915->pmu;
> >>> unsigned long flags;
> >>> - unsigned int bit;
> >>>
> >>> - bit = event_bit(event);
> >>> if (bit == -1)
> >>> goto update;
> >>>
> >>> @@ -651,7 +661,7 @@ static void i915_pmu_enable(struct perf_event
> >>> *event)
> >>> GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
> >>> GEM_BUG_ON(pmu->enable_count[bit] == ~0);
> >>>
> >>> - pmu->enable |= BIT_ULL(bit);
> >>> + pmu->enable |= BIT(bit);
> >>> pmu->enable_count[bit]++;
> >>>
> >>> /*
> >>> @@ -698,7 +708,7 @@ static void i915_pmu_disable(struct perf_event
> >>> *event)
> >>> {
> >>> struct drm_i915_private *i915 =
> >>> container_of(event->pmu, typeof(*i915), pmu.base);
> >>> - unsigned int bit = event_bit(event);
> >>> + const unsigned int bit = event_bit(event);
> >>> struct i915_pmu *pmu = &i915->pmu;
> >>> unsigned long flags;
> >>>
> >>> @@ -734,7 +744,7 @@ static void i915_pmu_disable(struct perf_event
> >>> *event)
> >>> * bitmask when the last listener on an event goes away.
> >>> */
> >>> if (--pmu->enable_count[bit] == 0) {
> >>> - pmu->enable &= ~BIT_ULL(bit);
> >>> + pmu->enable &= ~BIT(bit);
> >>> pmu->timer_enabled &= pmu_needs_timer(pmu, true);
> >>> }
> >>>
> >>> --
> >>> 2.36.1
> >>>
next prev parent reply other threads:[~2023-05-17 16:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-16 23:35 [Intel-gfx] [PATCH v5 0/7] Add MTL PMU support for multi-gt Umesh Nerlige Ramappa
2023-05-16 23:35 ` [Intel-gfx] [PATCH v5 1/7] drm/i915/pmu: Change bitmask of enabled events to u32 Umesh Nerlige Ramappa
2023-05-17 0:25 ` Dixit, Ashutosh
2023-05-17 6:55 ` Umesh Nerlige Ramappa
2023-05-17 8:26 ` Tvrtko Ursulin
2023-05-17 16:25 ` Dixit, Ashutosh [this message]
2023-05-17 20:15 ` Umesh Nerlige Ramappa
2023-05-17 20:15 ` Dixit, Ashutosh
2023-05-18 9:07 ` Tvrtko Ursulin
2023-05-19 5:02 ` Dixit, Ashutosh
2023-05-16 23:35 ` [Intel-gfx] [PATCH v5 2/7] drm/i915/pmu: Support PMU for all engines Umesh Nerlige Ramappa
2023-05-16 23:35 ` [Intel-gfx] [PATCH v5 3/7] drm/i915/pmu: Skip sampling engines with no enabled counters Umesh Nerlige Ramappa
2023-05-16 23:35 ` [Intel-gfx] [PATCH v5 4/7] drm/i915/pmu: Transform PMU parking code to be GT based Umesh Nerlige Ramappa
2023-05-16 23:35 ` [Intel-gfx] [PATCH v5 5/7] drm/i915/pmu: Add reference counting to the sampling timer Umesh Nerlige Ramappa
2023-05-16 23:35 ` [Intel-gfx] [PATCH v5 6/7] drm/i915/pmu: Prepare for multi-tile non-engine counters Umesh Nerlige Ramappa
2023-05-17 0:39 ` Dixit, Ashutosh
2023-05-17 6:57 ` Umesh Nerlige Ramappa
2023-05-16 23:35 ` [Intel-gfx] [PATCH v5 7/7] drm/i915/pmu: Export counters from all tiles Umesh Nerlige Ramappa
2023-05-17 0:35 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Add MTL PMU support for multi-gt Patchwork
2023-05-17 11:47 ` [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=87ednf3oyo.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox