On Fri, Jul 31, 2015 at 08:12:30PM +0530, Goel, Akash wrote:
>
>
> On 7/29/2015 5:34 PM, Chris Wilson wrote:
> >On Mon, Jul 27, 2015 at 11:38:13AM +0200, Daniel Vetter wrote:
> >>Chris and I just discussed on irc that the bound_list isn't in a great LRU
> >>order right now and Chris sent out a fix for that. But it only works if we
> >>preferrentially shrink inactive objects first. Worth the bother or just a
> >>FIXME? For the fb use-case alone it's not needed since we can't remove the
> >>fb until it's no longer being displayed (otherwise the backwards-compat
> >>code kicks in and synchronously kills the display at RMFB time), and that
> >>pretty much means we can't put the underlying bo into any cache (and mark
> >>it purgeable) either. But a FIXME comment here would be good for sure,
> >>just in case this assumption ever gets broken.
> >
> >I've been mucking around with patch a bit (with contexts-from-stolen
> >reenabled) and the list ierators used here are terrible; severely
> >impacting our allocations by a few orders of magnitude (imagine having
> >just the ggtt full of 4k objects, let alone several ppgtt all full of
> >their own bound 4k objetcs).
> >
> >To combat this will require a special purgeable list maintaind by
> >madv(), and subclassing the struct drm_mm_node to hold our extra
> >details.
>
> Should we add a separate purgeable list for stolen objects ?
>
>
> /** Stolen memory for this object, instead of being backed by shmem. */
> - struct drm_mm_node *stolen;
> + struct i915_gem_stolen *stolen;
>
>
> struct i915_gem_stolen {
> struct drm_mm_node *node;
> struct list_head purge_list;
> };
Almost. You will need a backpointer from the node to the object so you
can do your list iteration and purge the unwanted object.
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=1094f92e6d94190cf1334fd9bd6459ab70801455
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
