[Intel-gfx] [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
Chris Wilson
chris at chris-wilson.co.uk
Sun Aug 9 05:49:01 PDT 2015
On Sun, Aug 09, 2015 at 05:11:52PM +0530, Goel, Akash wrote:
>
>
> On 8/9/2015 4:25 PM, Chris Wilson wrote:
> >On Sun, Aug 09, 2015 at 04:23:01PM +0530, Goel, Akash wrote:
> >>On 8/7/2015 1:37 PM, Daniel Vetter wrote:
> >>>I presume though you only want to avoid clflush when actually purging an
> >>>object, so maybe we can keep this by purging the shmem backing node first
> >>>and checking here for __I915_MADV_PURGED instead?
> >>
> >>An object marked as MADV_DONT_NEED, implies that it will be
> >>purged/truncated right away after the call to put_pages_gtt
> >>function.
> >>So doing the other way round by purging first and then checking for
> >>__I915_MADV_PURGED, might be equivalent.
> >
> >But disregards a few nice sanity checks, which I would like to keep.
> >-Chris
> Fine, just wanted to convey that doing the other way round may not
> be really beneficial.
>
> About the other point of virtually indexed/physically tagged cache,
> would it be safe just rely on the MADV_DONT_NEED state of the object
> (which indicates that there are no active CPU mmappings) ?
> Due to an earlier CPU mmappings, there could be cachelines holding
> the stale data ?
If the conflicts survive munmap(), I don't have a clever idea on how to
avoid the clflush before we hand back the pages to the system.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list