[Intel-gfx] [PATCH 3/4] drm/i915: Add support for stealing purgable stolen pages
Goel, Akash
akash.goel at intel.com
Fri Jul 31 07:42:30 PDT 2015
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;
};
Best regards
Akash
> -Chris
>
More information about the Intel-gfx
mailing list