Hi Chris:
I begin to understand that before the "prev" context object is unpinned,
it's set to active by i915_vma_move_to_active, so the shrinker will wait for
it. Thanks for the help. Every time I learned a lot from you. Thanks. :)
-----Original Message-----
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, April 02, 2015 3:18 PM
To: Wang, Zhi A
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] looks like a issue in do_switch() and mi_set_context()
in i915_gem_context.c?
On Wed, Apr 01, 2015 at 08:01:56PM +0800, Zhi Wang wrote:
> Hi Chris:
> Thanks for the reply. :) I can understand that the backing storage
> is pinned at this time, as the reference counter of context object
> should not be zero. But for VMA, is there any chance that the vma will
> be unbinded from GGTT at this time by shrinker? I saw that
> i915_gem_object_ggtt_unpin() will decrease the VMA reference
> counter...
In order for the shrinker to evict an active object, it must first wait upon
it. (So the shrinker will only do so as a last gasp measure.) Once the vma is
unbound, we know that the GPU will have switched contexts away from the vma
(because the last request that we waited upon for the vma included the
instructions to do the switch away) and so the pages are swappable.
This obviously relies on the hardware being correct... As would waiting upon
the CCID!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
