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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
