On Tue, Jul 12, 2016 at 04:12:43PM +0100, Tvrtko Ursulin wrote: > > 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?
It won't, but it would try. Worse it would include the object in its estimates for shrinkable pages. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
