[Intel-gfx] [PATCH] drm/i915: Don't clflush purged objects on unbind

[Eric Anholt]

On Wed, 09 Dec 2009 09:01:18 +0000, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Tue, 08 Dec 2009 23:50:26 -0800, Eric Anholt <eric at anholt.net> wrote:
> > On Tue,  8 Dec 2009 22:17:20 +0000, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > If the object is marked as purgeable and we are about to simply truncate
> > > those pages, don't waste time by clearing the cache lines for the
> > > object.  In typical usage this saves around 10% of the clflushes.
> > 
> > What I'm concerned about here is a dirtied object: you've now flushed
> > the GPU cachelines to main memory, but the CPU might be sitting on some
> > read cachelines (see the madness in the pread path for partial cpu read
> > domain stuff, though speculation might also cause this).
> > 
> > Could that get us into trouble somehow?  I'm not exactly sure.
> 
> The difference is for an purgeable object we truncate the backing shmem
> object on unbind, so any access to its pages is verboten. Any attempt to
> rebind the object should generate an error.
> 
> During unbind, we simply take advantage of the knowledge that we are about
> to destroy those pages a few lines further down to avoid some expensive
> cache-line flushing. Before those (physical) pages can be used again the
> kernel will zero them, so I think this passes at all paranoia levels.
> -ickle

Yeah, the question was whether there was any danger in handing pages
back to the system where there may be read cachelines that are actually
not valid.  We couldn't convince ourselves last night that that was
definitely safe.  (Would the CPU drop a write of zeroes to a cacheline
where the cache said it was already full of zeroes?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20091209/b0fe8c00/attachment.sig>