On Sun, Aug 9, 2015 at 7:02 PM, Goel, Akash <akash.goel@xxxxxxxxx> wrote: > > > On 8/9/2015 6:19 PM, Chris Wilson wrote: >> >> 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. > > One case could be, as you suggested, check if ever there was a CPU mapping > created for the object & so avoid the clflush for GPU (GPU + GTT) only > objects. > We have verified (on BYT/CHV) that cachelines corresponding to object's pages do not get invalidated on munmap, so there is a possibility of stale data even when no CPU mappings are active. So we need to amend this patch to also check if ever there was a CPU mapping created for the object. Best regards Akash > Best regards > Akash >> >> -Chris >> > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
