public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>,
	"Dixit, Ashutosh" <ashutosh.dixit@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:26:15 +0100	[thread overview]
Message-ID: <0a1babb7-80cf-cfe7-4746-37b76934175a@linux.intel.com> (raw)
In-Reply-To: <ZGR6ZnjlUqerD+nY@orsosgc001.jf.intel.com>


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.. 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.

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
>>>

  reply	other threads:[~2023-05-17  8:26 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 [this message]
2023-05-17 16:25         ` Dixit, Ashutosh
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=0a1babb7-80cf-cfe7-4746-37b76934175a@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=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