All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: Bommu Krishnaiah <krishnaiah.bommu@intel.com>,
	intel-xe@lists.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: Re: [Intel-xe] [PATCH v5 3/3] drm/xe/pmu: Enable PMU interface
Date: Thu, 31 Aug 2023 16:57:25 -0700	[thread overview]
Message-ID: <2872a593-8c93-a7c4-331a-51dc946db581@intel.com> (raw)
In-Reply-To: <8734zy2471.wl-ashutosh.dixit@intel.com>


On 8/31/2023 4:16 PM, Dixit, Ashutosh wrote:
> On Thu, 31 Aug 2023 16:22:10 -0700, Belgaumkar, Vinay wrote:
>>>>>>> +static void xe_pmu_event_read(struct perf_event *event)
>>>>>>> +{
>>>>>>> +    struct xe_device *xe =
>>>>>>> +        container_of(event->pmu, typeof(*xe), pmu.base);
>>>>>>> +    struct hw_perf_event *hwc = &event->hw;
>>>>>>> +    struct xe_pmu *pmu = &xe->pmu;
>>>>>>> +    u64 prev, new;
>>>>>>> +
>>>>>>> +    if (pmu->closed) {
>>>>>>> +        event->hw.state = PERF_HES_STOPPED;
>>>>>>> +        return;
>>>>>>> +    }
>>>>>>> +again:
>>>>>>> +    prev = local64_read(&hwc->prev_count);
>>>>>>> +    new = __xe_pmu_event_read(event);
>>>>>>> +
>>>>>>> +    if (local64_cmpxchg(&hwc->prev_count, prev, new) != prev)
>>>>>>> +        goto again;
>>>>>>> +
>>>>>>> +    local64_add(new - prev, &event->count);
>>>>>>> +}
>>>>>>> +
>>>>>>> +static void xe_pmu_enable(struct perf_event *event)
>>>>>>> +{
>>>> The i915_pmu code checks which event is requested here and accordingly sets pmu->enable (which doesn't seem to be defined here yet). Any reason we are not doing this yet?
>>> in i915 pmu->enable is only used by events for which there is an internal timer sampler
>>> which periodically samples those events, this series is not adding such events.
>> Ok, the tracked events are bound by I915_NUM_PMU_SAMPLERS in i915, whereas
>> you have already defined the max non/tracking ones as
>> __XE_NUM_PMU_SAMPLERS, hence my confusion. Should we use a different name
>> in lieu of the tracked events which will be defined in subsequent patches?
>>
>> enum {
>>
>>          __I915_SAMPLE_FREQ_ACT = 0,
>>
>>          __I915_SAMPLE_FREQ_REQ,
>>          __I915_SAMPLE_RC6,
>>          __I915_SAMPLE_RC6_LAST_REPORTED,
>>          __I915_NUM_PMU_SAMPLERS
>>
>> };
> +enum {
> +       __XE_SAMPLE_RENDER_GROUP_BUSY,
> +       __XE_SAMPLE_COPY_GROUP_BUSY,
> +       __XE_SAMPLE_MEDIA_GROUP_BUSY,
> +       __XE_SAMPLE_ANY_ENGINE_GROUP_BUSY,
> +       __XE_NUM_PMU_SAMPLERS
> +};
> +
>
> I'd think any future events will be added after
> __XE_SAMPLE_ANY_ENGINE_GROUP_BUSY, changing the value of
> __XE_NUM_PMU_SAMPLERS, no? Why do we need a different name?

I guess that'll work, but the events in i915 are divided into ones that 
need the timer (non-engine) (max of I915_NUM_PMU_SAMPLERS) and the 
per-engine events (that don't need the timer). We now should have 3 
types? Non-engine-non-timer, non-engine-timer and per-engine?  Or just 
club together the non-engine ones?

Thanks,

Vinay.


  reply	other threads:[~2023-08-31 23:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30  5:15 [Intel-xe] [PATCH v5 0/3] drm/xe/pmu: Enable PMU interface Aravind Iddamsetty
2023-08-30  5:10 ` [Intel-xe] ✓ CI.Patch_applied: success for drm/xe/pmu: Enable PMU interface (rev5) Patchwork
2023-08-30  5:10 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-08-30  5:12 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-08-30  5:15 ` [Intel-xe] [PATCH v3 1/3] drm/xe: Get GT clock to nanosecs Aravind Iddamsetty
2023-08-30  5:15 ` [Intel-xe] [PATCH 2/3] drm/xe: Use spinlock in forcewake instead of mutex Aravind Iddamsetty
2023-08-30  5:33   ` Dixit, Ashutosh
2023-08-30 20:56     ` Rodrigo Vivi
2023-08-30 22:19       ` Dixit, Ashutosh
2023-08-31  4:13         ` Aravind Iddamsetty
2023-08-30  5:15 ` [Intel-xe] [PATCH v5 3/3] drm/xe/pmu: Enable PMU interface Aravind Iddamsetty
2023-08-30 20:58   ` Rodrigo Vivi
2023-08-31 20:45     ` Dixit, Ashutosh
2023-08-31 22:14       ` Aravind Iddamsetty
2023-08-31  4:48   ` Dixit, Ashutosh
2023-08-31 10:29     ` Aravind Iddamsetty
2023-08-31 16:58       ` Dixit, Ashutosh
2023-08-31 22:11         ` Aravind Iddamsetty
2023-08-31 22:21           ` Belgaumkar, Vinay
2023-08-31 23:11             ` Aravind Iddamsetty
2023-08-31 23:22               ` Belgaumkar, Vinay
2023-08-31 23:16                 ` Dixit, Ashutosh
2023-08-31 23:57                   ` Belgaumkar, Vinay [this message]
2023-08-31 23:58                     ` Dixit, Ashutosh
2023-09-01  3:34                       ` Aravind Iddamsetty
2023-08-30  5:19 ` [Intel-xe] ✓ CI.Build: success for drm/xe/pmu: Enable PMU interface (rev5) Patchwork
2023-08-30  5:19 ` [Intel-xe] ✗ CI.Hooks: 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=2872a593-8c93-a7c4-331a-51dc946db581@intel.com \
    --to=vinay.belgaumkar@intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=krishnaiah.bommu@intel.com \
    --cc=tvrtko.ursulin@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.