[Intel-gfx] [RFC 3/3] drm/i915: Add the truncation logic for Stolen objects.

[Gupta, Sourab]

Hi Daniel,

For stolen objects, we have not enabled the libdrm cacheing, so that when the user creates bo with this flag, the objects created are not cached.
Then the scenario of breaking the libdrm cacheing will not arise in this case.
This is ensured in the libdrm patches uploaded together with these patches. Can you please have a look at those patches.

Also, do we need to enable cacheing for stolen objects at libdrm ( therefore deferring the stolen object truncation to later) ?

Regards,
Sourab

-----Original Message-----
From: Vetter, Daniel 
Sent: Thursday, March 06, 2014 3:19 PM
To: Gupta, Sourab; Chris Wilson
Cc: intel-gfx at lists.freedesktop.org; Barnes, Jesse; Wilson, Chris; Goel, Akash
Subject: Re: [RFC 3/3] drm/i915: Add the truncation logic for Stolen objects.

On 06/03/2014 10:39, Gupta, Sourab wrote:
> Hi Daniel,
>
> We had also considered the two points where the stolen mem objs can be truncated -
> 	a) at the point of a new bo allocation, if stolen mem space is exhausted.
> 	b) at the point when the bo is marked as purgeable (madvise ioctl)
>
> We decided upon the second case because:
> 1) For normal objects, there is a bo cacheing at libdrm level. So even 
> after a bo is marked as purgeable, it can still get reused by libdrm (if not truncated already), thereby reducing the effort in new object creation.
> Currently for stolen objects we have not enabled this cacheing. So 
> once a stolen bo is marked as purgeable by User, Driver can 
> immediately reclaim the stolen space and there will be no obvious benefit in deferring the object truncation to a later stage (when there is a failure in allocation of a new bo).
> Actually we thought that since Stolen mem is a relatively much smaller 
> space and has a limited usage, there may not be any additional benefit gained by enabling bo cacheing on libdrm side.
> Also the effort in getting the backing space from stolen mem shall be much less than from shmem.
>
> With the first approach, it would have required us to scan the entire 
> list of bound & unbound objects to search for the purgeable stolen 
> objects and purge them. With the 2nd approach, we could avoid this & purge the objects we already have in our hand.
Well, approach b) breaks the libdrm cache, since libdrm sets the madvise flag to purgeable when insert an unused object into it's cache. So you really can't truncate the object right away, since that completely defeats the point of the cache.
-Daniel