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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
