From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: John Harrison <john.c.harrison@intel.com>,
"Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Matthew Brost <matthew.brost@intel.com>,
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: remove unneeded clflush calls
Date: Tue, 21 Sep 2021 16:06:00 +0300 [thread overview]
Message-ID: <YUnYuCFUVULQQK7j@intel.com> (raw)
In-Reply-To: <20210921054708.p63rjkxux742op72@ldmartin-desk2>
On Mon, Sep 20, 2021 at 10:47:08PM -0700, Lucas De Marchi wrote:
> On Wed, Sep 15, 2021 at 12:29:12PM -0700, John Harrison wrote:
> >On 9/15/2021 12:24, Belgaumkar, Vinay wrote:
> >>On 9/14/2021 12:51 PM, Lucas De Marchi wrote:
> >>>The clflush calls here aren't doing anything since we are not writting
> >>>something and flushing the cache lines to be visible to GuC. Here the
> >>>intention seems to be to make sure whatever GuC has written is visible
> >>>to the CPU before we read them. However a clflush from the CPU side is
> >>>the wrong instruction to use.
> >Is there a right instruction to use? Either we need to verify that no
>
> how can there be a right instruction? If the GuC needs to flush, then
> the GuC needs to do it, nothing to be done by the CPU.
>
> Flushing the CPU cache line here is doing nothing to guarantee that what
> was written by GuC hit the memory and we are reading it. Not sure why it
> was actually added, but since it was added by Vinay and he reviewed this
> patch, I'm assuming he also agrees
clflush == writeback + invalidate. The invalidate is the important part
when the CPU has to read something written by something else that's not
cache coherent.
Now, I have no idea if the guc has its own (CPU invisible) caches or not.
If it does then it will need to trigger a writeback. But regardless, if
the guc bypasses the CPU caches the CPU will need to invalidate before
it reads anything in case it has stale data sitting in its cache.
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2021-09-21 13:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-14 19:51 [Intel-gfx] [PATCH] drm/i915/guc/slpc: remove unneeded clflush calls Lucas De Marchi
2021-09-14 19:51 ` Lucas De Marchi
2021-09-14 20:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2021-09-14 20:35 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-09-14 23:57 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc/slpc: remove unneeded clflush calls (rev2) Patchwork
2021-09-15 0:28 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-09-15 2:39 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-09-15 19:24 ` [Intel-gfx] [PATCH] drm/i915/guc/slpc: remove unneeded clflush calls Belgaumkar, Vinay
2021-09-15 19:24 ` Belgaumkar, Vinay
2021-09-15 19:29 ` [Intel-gfx] " John Harrison
2021-09-15 19:29 ` John Harrison
2021-09-21 5:47 ` [Intel-gfx] " Lucas De Marchi
2021-09-21 5:47 ` Lucas De Marchi
2021-09-21 13:06 ` Ville Syrjälä [this message]
2021-09-23 5:37 ` [Intel-gfx] " Lucas De Marchi
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=YUnYuCFUVULQQK7j@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=john.c.harrison@intel.com \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@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.