From: Zhao Yakui <yakui.zhao@intel.com>
To: "Deak, Imre" <imre.deak@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Tamminen, Eero T" <eero.t.tamminen@intel.com>
Subject: Re: [PATCH v3 2/3] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config
Date: Wed, 13 Jul 2016 10:32:43 +0800 [thread overview]
Message-ID: <5785A84B.8030703@intel.com> (raw)
In-Reply-To: <1467380406-11954-3-git-send-email-imre.deak@intel.com>
On 07/01/2016 09:40 PM, Deak, Imre 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 LLC-UC
> 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. In the future we could also add a
> new MOCS entry for coherent surfaces.
>
> 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.
>
> With a follow-up change to adjust the 3rd entry value
> igt/gem_mocs_settings is passing after this change.
>
> v2:
> - Rebase on v2 of patch 1/2.
> v3:
> - Set the entry as LLC uncached instead of PTE-passthrough. This way
> we also keep snooping disabled, but we also make the cacheability/
> coherency setting indepent of the PTE which is managed by the
> kernel. (Chris)
>
> CC: Rong R Yang<rong.r.yang@intel.com>
> CC: Yakui Zhao<yakui.zhao@intel.com>
> 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>
> CC: Chris Wilson<chris@chris-wilson.co.uk>
> Signed-off-by: Imre Deak<imre.deak@intel.com>
As the BXT has no LLC, setting the WB-policy will add the extra
overhead. In such case the patch looks more reasonable for BXT.
Add: Acked-by: Zhao Yakui <yakui.zhao@intel.com>
> ---
> drivers/gpu/drm/i915/intel_mocs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c b/drivers/gpu/drm/i915/intel_mocs.c
> index d36e609..927825f 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -149,8 +149,8 @@ static const struct drm_i915_mocs_entry broxton_mocs_table[] = {
> .l3cc_value = L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
> },
> {
> - /* 0x0000003b */
> - .control_value = LE_CACHEABILITY(LE_WB) |
> + /* 0x00000039 */
> + .control_value = LE_CACHEABILITY(LE_UC) |
> 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),
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-07-13 1:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-01 13:40 [PATCH v3 0/3] drm/i915/bxt: Fix performance due to bogus MOCS entry Imre Deak
2016-07-01 13:40 ` [PATCH v3 1/3] drm/i915/gen9: Clean up MOCS table definitions Imre Deak
2016-07-01 21:23 ` Bish, Jim
2016-07-01 21:47 ` Francisco Jerez
2016-07-12 11:08 ` Imre Deak
2016-07-13 2:10 ` Zhao Yakui
2016-07-01 13:40 ` [PATCH v3 2/3] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config Imre Deak
2016-07-13 2:32 ` Zhao Yakui [this message]
2016-07-14 8:33 ` Yang, Rong R
2016-07-01 13:40 ` [PATCH v3 3/3] drm/i915: Give proper names to MOCS entries Imre Deak
2016-07-01 13:49 ` Chris Wilson
2016-07-01 13:56 ` Imre Deak
2016-07-01 14:32 ` [PATCH v4 " Imre Deak
2016-07-13 2:22 ` [PATCH v3 " Zhao Yakui
2016-07-13 10:04 ` Imre Deak
2016-07-14 1:38 ` Zhao Yakui
2016-07-01 14:54 ` ✗ Ro.CI.BAT: warning for drm/i915/bxt: Fix performance due to bogus MOCS entry Patchwork
2016-07-19 18:15 ` Imre Deak
2016-07-01 15:15 ` ✗ Ro.CI.BAT: warning for drm/i915/bxt: Fix performance due to bogus MOCS entry (rev2) Patchwork
2016-07-18 14:28 ` [PATCH v3 0/3] drm/i915/bxt: Fix performance due to bogus MOCS entry Ville Syrjälä
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=5785A84B.8030703@intel.com \
--to=yakui.zhao@intel.com \
--cc=eero.t.tamminen@intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/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.