Re: [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages

From: akash goel <akash.goels@gmail.com>
To: "Goel, Akash" <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
Date: Wed, 19 Aug 2015 19:54:25 +0530	[thread overview]
Message-ID: <CAK_0AV31jJ0R4+B1fiwtGxhLgXa=B=62VM4UvCefS8QDSPB0Gg@mail.gmail.com> (raw)
In-Reply-To: <55C7567F.20804@intel.com>

On Sun, Aug 9, 2015 at 7:02 PM, Goel, Akash <akash.goel@intel.com> 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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx