On 12/07/16 15:38, Chris Wilson wrote:
On Tue, Jul 12, 2016 at 03:30:25PM +0100, Tvrtko Ursulin wrote:
On 07/07/16 09:41, Chris Wilson wrote:
@@ -3684,6 +3684,9 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
old_read_domains,
old_write_domain);
+ /* Increment the pages_pin_count to guard against the shrinker */
+ obj->pages_pin_count++;
Would it be clearer to look at obj->pin_display in the shrinker?
Although it looks like special casing out of the cleanliness of the
design in both case so I am not sure.
Yeah. I liked the mechanism of telling the shrinker to avoid certain
pages by only having to control the pages_pin_count. It feels easier to
explain to others "the shrinker may reap any object that hasn't pinned
its pages" (explicitly called i915_gem_object_pin_pages for its own use)
rather than that + plus a list of exceptions known by the shrinker.
Hm but wait a minute, framebuffer already has the VMA pinned. So how
will the shrinker reap it?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
