[Intel-gfx] [PATCH v5 0/7] Command parser batch buffer copy
Daniel Vetter
daniel at ffwll.ch
Tue Dec 2 04:57:56 PST 2014
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
More information about the Intel-gfx
mailing list