On 05/03/2014 20:24, Gupta, Sourab wrote:
We have assumed the following lifecycle of the (stolen)object, w.r.t the truncation usecase:
1) The user creates the (non-cpu mappable)object --> the gem object is created. Shmem filep is allocated. No backing storage present
2) GPU operations performed (after mmap_gtt ) --> object is moved to stolen memory and the backing pages are allocated from stolen mem area.
3) Object is marked as purgeable (by madvise_ioctl)--> here two scenarios can occur:
a) Object has not yet been processed by GPU. In this case it will be in the active list. So, madvise_ioctl will mark it as purgeable and return.
Subsequently, when the retire handler runs, and object is being moved to inactive list, then, the purgeable object is truncated and marked as purged.
b) Object is already processed by the GPU. In this case, it will be in the inactive list. So, madvise_ioctl will do the object truncation and mark it as purged.
4) If object is not marked as purgeable, the backing pages of the object will remain.
5) When object is freed, backing pages are released, if the object has not been purged already.
Is the object being in the inactive list, the necessary and sufficient condition of it not being in use?
We may be missing out on some condition regarding when the object will be in use.
Can you please point us to the flaws in above assumption regarding when we can truncate the object.
Immediately purging the backing storage is not the idea of the madvise
ioctl. The idea is to purge it as late as possible, i.e. when we've
tried to allocate more stolen space but failed. For comparison see how
purgeable works for normal objects: Those only get purged in the
shrinker, i.e. when the linux mm is short on memory.
-Daniel
Intel Semiconductor AG
Registered No. 020.30.913.786-7
Registered Office: World Trade Center, Leutschenbachstrasse 95, 8050 Zurich, Switzerland
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
