Re: [PATCH 3/4] drm/i915: Add support for stealing purgable stolen pages

From: "Goel, Akash" <akash.goel@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org,
	shashidhar.hiremath@intel.com
Subject: Re: [PATCH 3/4] drm/i915: Add support for stealing purgable stolen pages
Date: Fri, 31 Jul 2015 22:04:26 +0530	[thread overview]
Message-ID: <55BBA392.7050907@intel.com> (raw)
In-Reply-To: <20150731150637.GC31727@nuc-i3427.alporthouse.com>

On 7/31/2015 8:36 PM, Chris Wilson wrote:
> 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.
Agree that a back pointer is also needed, as the stolen structure will 
not be embedded in the object structure. Thanks.

> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=1094f92e6d94190cf1334fd9bd6459ab70801455

More thanks for providing the reference implementation.

Best regards
Akash
> -Chris
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx