All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	Valtteri Rantala <valtteri.rantala@intel.com>,
	Eero Tamminen <eero.t.tamminen@intel.com>,
	Michael T Frederick <michael.t.frederick@intel.com>
Subject: Re: [PATCH 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config
Date: Mon, 25 Apr 2016 13:49:14 +0100	[thread overview]
Message-ID: <20160425124914.GE4033@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <1461587994.20143.9.camel@intel.com>

On Mon, Apr 25, 2016 at 03:39:54PM +0300, Imre Deak wrote:
> On ma, 2016-04-25 at 13:37 +0100, Chris Wilson wrote:
> > On Mon, Apr 25, 2016 at 03:23:21PM +0300, Imre Deak wrote:
> > > Setting a write-back cache policy in the MOCS entry definition also
> > > implies snooping, which has a considerable overhead. This is
> > > unexpected for a few reasons:
> > > - From user-space's point of view since it didn't want a coherent
> > >   surface (it didn't set the buffer as such via the set caching
> > > IOCTL).
> > > - There is a separate MOCS entry field for snooping (which we never
> > >   set).
> > > - This MOCS table is about caching in (e)LLC and there is no (e)LLC
> > > on
> > >   BXT. There is a separate table for L3 cache control.
> > > 
> > > Considering the above the current behavior of snooping looks like
> > > an
> > > unintentional side-effect of the WB setting. Changing it to be PTE
> > > based cacheability gets rid of the snooping without any ill-
> > > effects.
> > > For a coherent surface the application would use a separate MOCS
> > > entry
> > > (at index 1) and call the set caching IOCTL to setup the PTE
> > > entries
> > > for the corresponding buffer to be snooped.
> > > 
> > > This resulted in 70% improvement in synthetic texturing benchmarks.
> > > 
> > > Kudos to Valtteri Rantala, Eero Tamminen and Michael T Frederick
> > > and
> > > Ville who helped to narrow the source of problem to the kernel and
> > > to
> > > the snooping behaviour in particular.
> > > 
> > > CC: Valtteri Rantala <valtteri.rantala@intel.com>
> > > CC: Eero Tamminen <eero.t.tamminen@intel.com>
> > > CC: Michael T Frederick <michael.t.frederick@intel.com>
> > > CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_mocs.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> > > b/drivers/gpu/drm/i915/intel_mocs.c
> > > index 5006a92..23c7dd1 100644
> > > --- a/drivers/gpu/drm/i915/intel_mocs.c
> > > +++ b/drivers/gpu/drm/i915/intel_mocs.c
> > > @@ -142,7 +142,7 @@ static const struct drm_i915_mocs_entry
> > > broxton_mocs_table[] = {
> > >  	  .l3cc_value =    L3_ESC(0) | L3_SCC(0) |
> > > L3_CACHEABILITY(L3_WB),
> > >  	},
> > >  	{
> > > -	  .control_value = LE_CACHEABILITY(LE_WB) |
> > > +	  .control_value = LE_CACHEABILITY(LE_PAGETABLE) |
> > >  			   LE_TGT_CACHE(LE_TC_LLC_ELLC) |
> > >  			   LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) |
> > > LE_SCC(0) |
> > >  			   LE_PFM(0) | LE_SCF(0),
> > 
> > This is index 2? This should *be* the snooping entry?
> > 
> > Index 0: uncached
> > Index 1: follow pte
> > Index 2: snoop
> > 
> > Aim I missing something? Why isn't this a userspce bug for requesting
> > a
> > mocs setting it didn't wnat? In my kernel this makes mocs_table[1] ==
> > mocs_table[2].
> 
> I don't think there is or can be any snooping entry. On CHV for example
> we can only setup snooping via the PTE, so there we necessarily have to
> use entry 1 + PTE setup (set caching IOCTL). This is also what both
> Windows and Mesa assumes apparently.

Then the issue is not we've enabled snooping via mocs, but that the mocs
entry is completely bogus. Please update your commit message :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-04-25 12:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-25 12:23 [PATCH 1/2] drm/i915/gen9: Clean up MOCS table definitions Imre Deak
2016-04-25 12:23 ` [PATCH 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config Imre Deak
2016-04-25 12:37   ` Chris Wilson
2016-04-25 12:39     ` Imre Deak
2016-04-25 12:49       ` Chris Wilson [this message]
2016-04-25 13:01         ` Imre Deak
2016-04-25 12:30 ` [PATCH 1/2] drm/i915/gen9: Clean up MOCS table definitions Chris Wilson
2016-04-25 17:26   ` Imre Deak
2016-04-25 12:55 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] " 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=20160425124914.GE4033@nuc-i3427.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=eero.t.tamminen@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michael.t.frederick@intel.com \
    --cc=valtteri.rantala@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.