[PATCH] drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[PATCH] drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Chris Wilson]

When we need to rebind the vma into the global GTT for snb, we need to
drop the current reloc_cache as it will be holding a kmap_atomic() and
we may need to sleep for i915_vma_bind(). In practice, this is not an
issue as we already hold an rpm reference for the execbuffer, but with
tighter error checking around rpm we need to be more careful.

References: 31a39207f04a ("drm/i915: Cache kmap between relocations")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index b15305f2fb76..8c34b1b5a126 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1315,6 +1315,12 @@ eb_relocate_entry(struct i915_execbuffer *eb,
 		 */
 		if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
 		    IS_GEN6(eb->i915)) {
+			/*
+			 * Release the kmap_atomic cache in order to allow the
+			 * i915_vma_bind() to sleep (if needs be).
+			 */
+			reloc_cache_reset(&eb->reloc_cache);
+
 			err = i915_vma_bind(target, target->obj->cache_level,
 					    PIN_GLOBAL);
 			if (WARN_ONCE(err,
-- 
2.16.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Patchwork]

== Series Details ==

Series: drm/i915: Release the atomic kmap relocation cache around snb GTT w/a
URL   : https://patchwork.freedesktop.org/series/38107/
State : success

== Summary ==

Series 38107v1 drm/i915: Release the atomic kmap relocation cache around snb GTT w/a
https://patchwork.freedesktop.org/api/1.0/series/38107/revisions/1/mbox/

Test gem_mmap_gtt:
        Subgroup basic-small-bo-tiledx:
                fail       -> PASS       (fi-gdg-551) fdo#102575
Test prime_vgem:
        Subgroup basic-fence-flip:
                fail       -> PASS       (fi-ilk-650)

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u     total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  time:447s
fi-bdw-gvtdvm    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:422s
fi-blb-e6850     total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  time:375s
fi-bsw-n3050     total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  time:489s
fi-bwr-2160      total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 time:289s
fi-bxt-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:485s
fi-bxt-j4205     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:490s
fi-byt-j1900     total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  time:476s
fi-byt-n2820     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:461s
fi-cfl-s2        total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:567s
fi-cnl-y3        total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:587s
fi-elk-e7500     total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  time:416s
fi-gdg-551       total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 time:286s
fi-glk-1         total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:515s
fi-hsw-4770      total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  time:413s
fi-ilk-650       total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  time:413s
fi-ivb-3520m     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:450s
fi-ivb-3770      total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  time:418s
fi-kbl-7500u     total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  time:458s
fi-kbl-7560u     total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  time:496s
fi-kbl-r         total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:502s
fi-pnv-d510      total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  time:590s
fi-skl-6260u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:428s
fi-skl-6600u     total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:508s
fi-skl-6700hq    total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:529s
fi-skl-6700k2    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:489s
fi-skl-6770hq    total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:473s
fi-skl-guc       total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:413s
fi-skl-gvtdvm    total:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  time:436s
fi-snb-2520m     total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:526s
fi-snb-2600      total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:399s
Blacklisted hosts:
fi-glk-dsi       total:117  pass:104  dwarn:0   dfail:0   fail:0   skip:12 

83878f486e686dd291ef3566a45103962d7617ed drm-tip: 2018y-02m-12d-17h-43m-07s UTC integration manifest
900fa4b282bc drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7986/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.IGT: failure for drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Patchwork]

== Series Details ==

Series: drm/i915: Release the atomic kmap relocation cache around snb GTT w/a
URL   : https://patchwork.freedesktop.org/series/38107/
State : failure

== Summary ==

Test kms_mmio_vs_cs_flip:
        Subgroup setcrtc_vs_cs_flip:
                skip       -> PASS       (shard-apl)
Test kms_cursor_legacy:
        Subgroup flip-vs-cursor-crc-legacy:
                skip       -> PASS       (shard-apl)
        Subgroup cursora-vs-flipa-legacy:
                skip       -> PASS       (shard-apl)
Test kms_frontbuffer_tracking:
        Subgroup fbc-1p-offscren-pri-indfb-draw-render:
                skip       -> PASS       (shard-apl) fdo#103167
Test kms_flip:
        Subgroup blocking-absolute-wf_vblank:
                skip       -> PASS       (shard-apl)
        Subgroup wf_vblank-ts-check-interruptible:
                skip       -> PASS       (shard-apl) fdo#100368
Test kms_rmfb:
        Subgroup rmfb-ioctl:
                skip       -> PASS       (shard-apl)
Test kms_color:
        Subgroup pipe-b-ctm-green-to-red:
                skip       -> PASS       (shard-apl)
        Subgroup pipe-c-ctm-max:
                skip       -> PASS       (shard-apl)
        Subgroup pipe-c-degamma:
                skip       -> PASS       (shard-apl)
Test kms_rotation_crc:
        Subgroup exhaust-fences:
                skip       -> PASS       (shard-apl)
Test perf:
        Subgroup oa-exponents:
                fail       -> PASS       (shard-apl) fdo#102254
Test pm_rpm:
        Subgroup i2c:
                pass       -> FAIL       (shard-hsw)
        Subgroup gem-mmap-cpu:
                skip       -> PASS       (shard-apl)
        Subgroup system-suspend-modeset:
                skip       -> PASS       (shard-apl)
Test kms_plane_scaling:
        Subgroup pipe-a-scaler-with-rotation:
                skip       -> PASS       (shard-apl)
Test kms_vblank:
        Subgroup pipe-b-wait-busy:
                skip       -> PASS       (shard-apl)

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-apl        total:3410 pass:1769 dwarn:1   dfail:0   fail:20  skip:1619 time:13741s
shard-hsw        total:3427 pass:1715 dwarn:1   dfail:0   fail:56  skip:1654 time:14754s
shard-snb        total:3427 pass:1349 dwarn:1   dfail:0   fail:10  skip:2067 time:7655s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7986/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Tvrtko Ursulin]

On 12/02/2018 21:11, Chris Wilson wrote:
> When we need to rebind the vma into the global GTT for snb, we need to
> drop the current reloc_cache as it will be holding a kmap_atomic() and
> we may need to sleep for i915_vma_bind(). In practice, this is not an
> issue as we already hold an rpm reference for the execbuffer, but with
> tighter error checking around rpm we need to be more careful.
> 
> References: 31a39207f04a ("drm/i915: Cache kmap between relocations")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
>   drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index b15305f2fb76..8c34b1b5a126 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1315,6 +1315,12 @@ eb_relocate_entry(struct i915_execbuffer *eb,
>   		 */
>   		if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
>   		    IS_GEN6(eb->i915)) {
> +			/*
> +			 * Release the kmap_atomic cache in order to allow the
> +			 * i915_vma_bind() to sleep (if needs be).
> +			 */
> +			reloc_cache_reset(&eb->reloc_cache);
> +
>   			err = i915_vma_bind(target, target->obj->cache_level,
>   					    PIN_GLOBAL);
>   			if (WARN_ONCE(err,
> 

Hmm yes, very interesting. If you are happy with the performance hit then:

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

But in general could it also be solved by changing how 
intel_runtime_pm_get works - making our wakeref_count top level and only 
calling pm_runtime_get_sync on 0 to 1 transition? That would solve the 
issue with proposed might_sleep and code paths which know the condition 
is actually impossible.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-13 13:42:03)
> 
> On 12/02/2018 21:11, Chris Wilson wrote:
> > When we need to rebind the vma into the global GTT for snb, we need to
> > drop the current reloc_cache as it will be holding a kmap_atomic() and
> > we may need to sleep for i915_vma_bind(). In practice, this is not an
> > issue as we already hold an rpm reference for the execbuffer, but with
> > tighter error checking around rpm we need to be more careful.
> > 
> > References: 31a39207f04a ("drm/i915: Cache kmap between relocations")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > ---
> >   drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++++++
> >   1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index b15305f2fb76..8c34b1b5a126 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1315,6 +1315,12 @@ eb_relocate_entry(struct i915_execbuffer *eb,
> >                */
> >               if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
> >                   IS_GEN6(eb->i915)) {
> > +                     /*
> > +                      * Release the kmap_atomic cache in order to allow the
> > +                      * i915_vma_bind() to sleep (if needs be).
> > +                      */
> > +                     reloc_cache_reset(&eb->reloc_cache);
> > +
> >                       err = i915_vma_bind(target, target->obj->cache_level,
> >                                           PIN_GLOBAL);
> >                       if (WARN_ONCE(err,
> > 
> 
> Hmm yes, very interesting. If you are happy with the performance hit then:
> 
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> But in general could it also be solved by changing how 
> intel_runtime_pm_get works - making our wakeref_count top level and only 
> calling pm_runtime_get_sync on 0 to 1 transition? That would solve the 
> issue with proposed might_sleep and code paths which know the condition 
> is actually impossible.

I think we should do that anyway to reduce the jitter we see in calling
pm_runtime_get_sync().
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Chris Wilson]

Quoting Chris Wilson (2018-02-13 13:45:33)
> Quoting Tvrtko Ursulin (2018-02-13 13:42:03)
> > 
> > On 12/02/2018 21:11, Chris Wilson wrote:
> > > When we need to rebind the vma into the global GTT for snb, we need to
> > > drop the current reloc_cache as it will be holding a kmap_atomic() and
> > > we may need to sleep for i915_vma_bind(). In practice, this is not an
> > > issue as we already hold an rpm reference for the execbuffer, but with
> > > tighter error checking around rpm we need to be more careful.
> > > 
> > > References: 31a39207f04a ("drm/i915: Cache kmap between relocations")
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > ---
> > >   drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++++++
> > >   1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > index b15305f2fb76..8c34b1b5a126 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > @@ -1315,6 +1315,12 @@ eb_relocate_entry(struct i915_execbuffer *eb,
> > >                */
> > >               if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
> > >                   IS_GEN6(eb->i915)) {
> > > +                     /*
> > > +                      * Release the kmap_atomic cache in order to allow the
> > > +                      * i915_vma_bind() to sleep (if needs be).
> > > +                      */
> > > +                     reloc_cache_reset(&eb->reloc_cache);
> > > +
> > >                       err = i915_vma_bind(target, target->obj->cache_level,
> > >                                           PIN_GLOBAL);
> > >                       if (WARN_ONCE(err,
> > > 
> > 
> > Hmm yes, very interesting. If you are happy with the performance hit then:
> > 
> > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > 
> > But in general could it also be solved by changing how 
> > intel_runtime_pm_get works - making our wakeref_count top level and only 
> > calling pm_runtime_get_sync on 0 to 1 transition? That would solve the 
> > issue with proposed might_sleep and code paths which know the condition 
> > is actually impossible.
> 
> I think we should do that anyway to reduce the jitter we see in calling
> pm_runtime_get_sync().

I recall the challenge lay in the asserts which also bump our counter to
hide themselves.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Release the atomic kmap relocation cache around snb GTT w/a

[Tvrtko Ursulin]

On 13/02/2018 13:46, Chris Wilson wrote:
> Quoting Chris Wilson (2018-02-13 13:45:33)
>> Quoting Tvrtko Ursulin (2018-02-13 13:42:03)
>>>
>>> On 12/02/2018 21:11, Chris Wilson wrote:
>>>> When we need to rebind the vma into the global GTT for snb, we need to
>>>> drop the current reloc_cache as it will be holding a kmap_atomic() and
>>>> we may need to sleep for i915_vma_bind(). In practice, this is not an
>>>> issue as we already hold an rpm reference for the execbuffer, but with
>>>> tighter error checking around rpm we need to be more careful.
>>>>
>>>> References: 31a39207f04a ("drm/i915: Cache kmap between relocations")
>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++++++
>>>>    1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>>>> index b15305f2fb76..8c34b1b5a126 100644
>>>> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>>>> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>>>> @@ -1315,6 +1315,12 @@ eb_relocate_entry(struct i915_execbuffer *eb,
>>>>                 */
>>>>                if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
>>>>                    IS_GEN6(eb->i915)) {
>>>> +                     /*
>>>> +                      * Release the kmap_atomic cache in order to allow the
>>>> +                      * i915_vma_bind() to sleep (if needs be).
>>>> +                      */
>>>> +                     reloc_cache_reset(&eb->reloc_cache);
>>>> +
>>>>                        err = i915_vma_bind(target, target->obj->cache_level,
>>>>                                            PIN_GLOBAL);
>>>>                        if (WARN_ONCE(err,
>>>>
>>>
>>> Hmm yes, very interesting. If you are happy with the performance hit then:
>>>
>>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> But in general could it also be solved by changing how
>>> intel_runtime_pm_get works - making our wakeref_count top level and only
>>> calling pm_runtime_get_sync on 0 to 1 transition? That would solve the
>>> issue with proposed might_sleep and code paths which know the condition
>>> is actually impossible.
>>
>> I think we should do that anyway to reduce the jitter we see in calling
>> pm_runtime_get_sync().
> 
> I recall the challenge lay in the asserts which also bump our counter to
> hide themselves.

Not so easy then. Plan B - do not merge this patch nor my might sleep, 
but set up a cron job to send the latter for CI once a month. :)

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx