All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	Vinay Belgaumkar <vinay.belgaumkar@intel.com>,
	Riana Tauro <riana.tauro@intel.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	<linux-perf-users@vger.kernel.org>
Subject: Re: [PATCH v15 3/6] drm/xe/pmu: Extract xe_pmu_event_update()
Date: Thu, 23 Jan 2025 10:24:22 -0500	[thread overview]
Message-ID: <Z5JfJmEPNrDd0HLH@intel.com> (raw)
In-Reply-To: <djk45hhruejm5yzsvyn7jfmby6holhyhfk74xnbkxmot2yqmwf@l2kz7pjdxvvp>

On Thu, Jan 23, 2025 at 08:59:16AM -0600, Lucas De Marchi wrote:
> On Thu, Jan 23, 2025 at 05:20:09AM -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 22, 2025 at 08:19:20PM -0800, Lucas De Marchi wrote:
> > > Like other pmu drivers, keep the update separate from the read so it can
> > > be called from other methods (like stop()) without side effects.
> > > 
> > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_pmu.c | 24 +++++++++++++++---------
> > >  1 file changed, 15 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_pmu.c b/drivers/gpu/drm/xe/xe_pmu.c
> > > index df93ba96bdc1e..33598272db6aa 100644
> > > --- a/drivers/gpu/drm/xe/xe_pmu.c
> > > +++ b/drivers/gpu/drm/xe/xe_pmu.c
> > > @@ -117,18 +117,11 @@ static u64 __xe_pmu_event_read(struct perf_event *event)
> > >  	return val;
> > >  }
> > > 
> > > -static void xe_pmu_event_read(struct perf_event *event)
> > > +static void xe_pmu_event_update(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->registered) {
> > > -		event->hw.state = PERF_HES_STOPPED;
> > > -		return;
> > > -	}
> > > -
> > >  	prev = local64_read(&hwc->prev_count);
> > >  	do {
> > >  		new = __xe_pmu_event_read(event);
> > 
> > I really have the feeling that the names are inverted, and that this
> > function should be the one actually called read, but I double
> > checked and everybody else is doing the same, so I guess I just need
> > more coffee...
> 
> yeah... that's because "read" here is used in 2 different contexts:
> 
> 1) as implementation of the perf_pmu functor. We are implementing the
> .event_read() so we call the function xe_pmu_event_read()
> 2) as the verb implying we are reading the HW since it's commonly used
> in xe, so we call the function __xe_pmu_event_read()
> 
> however the perf_pmu implies that the HW values are updated not only in
> the .read() call, but also in e.g. in the .stop() call. So we have
> 
> 	xe_pmu_event_stop
> 	  xe_pmu_event_update
> 	    __xe_pmu_event_read
> 
> and
> 
> 	xe_pmu_event_read
> 	  xe_pmu_event_update
> 	    __xe_pmu_event_read
> 

This kind of makes sense now, or at least explains my own confusion...

> __xe_pmu_event_read could be called event_hw_readout() or something like
> that if it helps clearing up the confusion. Thoughts?
> 
> > 
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> 
> let me know what you think about the rename above and I will keep your
> r-b.

No no, let's continue with the style that is used everywhere...

> 
> thanks
> Lucas De Marchi
> 
> > 
> > > @@ -137,6 +130,19 @@ static void xe_pmu_event_read(struct perf_event *event)
> > >  	local64_add(new - prev, &event->count);
> > >  }
> > > 
> > > +static void xe_pmu_event_read(struct perf_event *event)
> > > +{
> > > +	struct xe_device *xe = container_of(event->pmu, typeof(*xe), pmu.base);
> > > +	struct xe_pmu *pmu = &xe->pmu;
> > > +
> > > +	if (!pmu->registered) {
> > > +		event->hw.state = PERF_HES_STOPPED;
> > > +		return;
> > > +	}
> > > +
> > > +	xe_pmu_event_update(event);
> > > +}
> > > +
> > >  static void xe_pmu_enable(struct perf_event *event)
> > >  {
> > >  	/*
> > > @@ -166,7 +172,7 @@ static void xe_pmu_event_stop(struct perf_event *event, int flags)
> > > 
> > >  	if (pmu->registered)
> > >  		if (flags & PERF_EF_UPDATE)
> > > -			xe_pmu_event_read(event);
> > > +			xe_pmu_event_update(event);
> > > 
> > >  	event->hw.state = PERF_HES_STOPPED;
> > >  }
> > > --
> > > 2.48.0
> > > 

  reply	other threads:[~2025-01-23 15:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-23  4:19 [PATCH v15 0/6] drm/xe/pmu: PMU interface for Xe Lucas De Marchi
2025-01-23  4:19 ` [PATCH v15 1/6] drm/xe/pmu: Enable PMU interface Lucas De Marchi
2025-01-23  4:19 ` [PATCH v15 2/6] drm/xe/pmu: Assert max gt Lucas De Marchi
2025-01-23  4:19 ` [PATCH v15 3/6] drm/xe/pmu: Extract xe_pmu_event_update() Lucas De Marchi
2025-01-23 10:20   ` Rodrigo Vivi
2025-01-23 14:59     ` Lucas De Marchi
2025-01-23 15:24       ` Rodrigo Vivi [this message]
2025-01-23  4:19 ` [PATCH v15 4/6] drm/xe/pmu: Add attribute skeleton Lucas De Marchi
2025-01-23 10:13   ` Rodrigo Vivi
2025-01-23 13:54   ` Riana Tauro
2025-01-23 14:48     ` Lucas De Marchi
2025-01-23 15:02       ` Riana Tauro
2025-01-23 16:36         ` Lucas De Marchi
2025-01-23  4:19 ` [PATCH v15 5/6] drm/xe/pmu: Get/put runtime pm on event init Lucas De Marchi
2025-01-23  4:19 ` [PATCH v15 6/6] drm/xe/pmu: Add GT C6 events Lucas De Marchi
2025-01-23  4:29 ` ✓ CI.Patch_applied: success for drm/xe/pmu: PMU interface for Xe (rev15) Patchwork
2025-01-23  4:29 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-23  4:30 ` ✓ CI.KUnit: success " Patchwork
2025-01-23  4:47 ` ✓ CI.Build: " Patchwork
2025-01-23  4:49 ` ✓ CI.Hooks: " Patchwork
2025-01-23  4:51 ` ✓ CI.checksparse: " Patchwork
2025-01-23  5:17 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-23 15:16 ` ✗ Xe.CI.Full: 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=Z5JfJmEPNrDd0HLH@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=peterz@infradead.org \
    --cc=riana.tauro@intel.com \
    --cc=vinay.belgaumkar@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.