All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Matt Atwood <matthew.s.atwood@intel.com>
Cc: intel-gfx@lists.freedesktop.org, Andi Shyti <andi.shyti@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: sync I915_PMU_MAX_GTS to I915_MAX_GT
Date: Thu, 01 Jun 2023 17:23:24 -0700	[thread overview]
Message-ID: <87ttvqvhj7.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <87v8g7ujaj.wl-ashutosh.dixit@intel.com>

On Thu, 01 Jun 2023 11:30:44 -0700, Dixit, Ashutosh wrote:
>
> On Thu, 01 Jun 2023 11:22:18 -0700, Dixit, Ashutosh wrote:
> >
> > On Wed, 31 May 2023 14:35:47 -0700, Matt Atwood wrote:
> > >
> >
> > Hi Matt,
> >
> > > Set I915_PMU_MAX_GTS to value in I915_MAX_GT, theres no reason for these
> > > values to be different.
>
> Also, we can't be so sure so as to be able to say "theres no reason for
> these values to be different" till we have actually verified it. E.g. there
> are various bitfields in the code which might not fit in a u32 if we
> increase MAX_GT from 2 to 4. Has this been verified?
>
> If anything, to keep the code from doing unnecessary stuff, IMO I915_MAX_GT
> should be reduced to 2 and should be increased to 4 only once/if we have
> i915 supported platforms with 4 GT's.

Matt explained the issue offline to me (it would have helped to explain the
reason for the patch in the commit message). The issue is that in uses of
for_each_gt such as below (there are others too in the PMU code):

        for_each_gt(gt, i915, i) {
                intel_wakeref_t wakeref;

                with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
                        u64 val = __get_rc6(gt);

                        store_sample(pmu, i, __I915_SAMPLE_RC6, val);
                        store_sample(pmu, i, __I915_SAMPLE_RC6_LAST_REPORTED,
                                     val);
                        pmu->sleep_last[i] = ktime_get_raw();
                }
        }

static checkers are complaining that for_each_gt can read/write outside the
bounds of PMU arrays. Because absent gt's will be NULL in for_each_gt this
cannot really happen but we still need to keep static checkers happy.

So to resolve this issue we need I915_PMU_MAX_GTS and I915_MAX_GT to have
the same value. So either we need to increase I915_PMU_MAX_GTS to 4 or
reduce I915_MAX_GT to 2.

Regards,
Ashutosh

>
>
> > >
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > > Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
> > > Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> >
> > I don't believe the mailer actually Cc'd us. I just saw this and am Cc'ing
> > the people who authored/reviewed the previous series now.
> >
> > > Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_pmu.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
> > > index 33d80fbaab8b..aa929d8c224a 100644
> > > --- a/drivers/gpu/drm/i915/i915_pmu.h
> > > +++ b/drivers/gpu/drm/i915/i915_pmu.h
> > > @@ -38,7 +38,7 @@ enum {
> > >	__I915_NUM_PMU_SAMPLERS
> > >  };
> > >
> > > -#define I915_PMU_MAX_GTS 2
> > > +#define I915_PMU_MAX_GTS 4
> >
> > This was a discussed during the previous review and it was decided to keep
> > the two values (I915_PMU_MAX_GTS and I915_MAX_GT) different. There are
> > currently no platforms and there will be no i915 supported platforms with
> > MAX_GT 4. So I prefer to leave the values as they currently are. Unless
> > Umesh or Tvrtko agrees to this patch.
> >
> > Thanks.
> > --
> > Ashutosh
> >
> > >
> > >  /*
> > >   * How many different events we track in the global PMU mask.
> > > --
> > > 2.40.0
> > >

  reply	other threads:[~2023-06-02  0:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-31 21:35 [Intel-gfx] [PATCH] drm/i915: sync I915_PMU_MAX_GTS to I915_MAX_GT Matt Atwood
2023-05-31 21:48 ` Andi Shyti
2023-05-31 22:07   ` Matt Atwood
2023-05-31 22:15     ` Andi Shyti
2023-06-01 17:40       ` Andi Shyti
2023-06-01  1:32 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2023-06-01  1:46 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-06-01 18:22 ` [Intel-gfx] [PATCH] " Dixit, Ashutosh
2023-06-01 18:30   ` Dixit, Ashutosh
2023-06-02  0:23     ` Dixit, Ashutosh [this message]
2023-06-02  0:40       ` Andi Shyti
2023-06-02  3:21         ` Dixit, Ashutosh
2023-06-02  8:51           ` Andi Shyti
2023-06-01 18:52   ` Umesh Nerlige Ramappa
2023-06-02 16:19 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2023-06-02 21:40 [Intel-gfx] [PATCH] " Matt Atwood
2023-06-02 22:26 ` Matt Roper

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=87ttvqvhj7.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=andi.shyti@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.s.atwood@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.