On Tue, Dec 02, 2014 at 11:13:48AM +0000, Chris Wilson wrote: > On Mon, Dec 01, 2014 at 02:39:51PM -0800, Michael H. Nguyen wrote: > > Re: madvise on creation > > > > Were you referring to this? > > > > from http://lists.freedesktop.org/archives/intel-gfx/2014-November/055060.htm > > > > obj = i915_gem_obj_alloc(); > > i915_gem_object_get_pages(obj); > > obj->madv = I915_MADV_DONTNEED; > > > > If so, I don't understand . _get is returning obj and it'll be > > needed so would expect to set 'obj->madv = I915_MADV_WILLNEED' which > > is the case now. > > madv is only evaluated at get_pages(). Once you have the pages, you keep > them until the shrinker purges them. Hence you only need to call > get_pages() once and set obj->madv = DONTNEED afterwards, and then you > only need to check whether the obj is purged before your next reuse (you > do not need to touch madv ever again). Whilst the object is active it is > a low priority target for the shrinker. That greatly simplifies the pool > code. Well we must pin the pages while the obj/vma hasn't yet transferred to the active list (like all execbuf objs). Otherwise someone might steal this at the next allocation point. But that's really just to clarify the implications of what Chris explained here, iirc the current shadow copy code should take care of all that (with the pending review on Brad's last version addressed ofc). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
