It's correct that exported buffers can't be moved to another domain or
swapped to disk while another device is using it.
But for imports that's a different story:
an imported object should never end up on a LRU list in TTM because
TTM wouldn't know how to evict it.
Even currently the imported objects are actually added to the LRU. The
problem is just that they are not added immediately during creation, but
only with the first command submission.
E.g. what you can do as userspace process is importing a lot of buffers
from a different device into the GFX drivers and never use it. This way
you can force the kernel into running out of GTT address space.
Regards,
Christian.
Am 09.01.2016 um 08:05 schrieb Thomas Hellstrom:
Hi!
I might be misunderderstanding the use-case here, but IIRC the
discussion with TTM vs imported / exported buffer objects is that a
buffer object needs to be marked NO_EVICT in TTM before it's exported
and an imported object should never end up on a LRU list in TTM because
TTM wouldn't know how to evict it.
/Thomas
On 01/08/2016 02:41 PM, Christian König wrote:
From: Christian König <christian.koenig@xxxxxxx>
If we import a BO with an eternal reservation object we don't
reserve/unreserve it. So we never add it to the LRU causing a possible
deny of service.
Signed-off-by: Christian König <christian.koenig@xxxxxxx>
---
drivers/gpu/drm/ttm/ttm_bo.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 745e996..a98a5d5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1170,9 +1170,15 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
if (likely(!ret))
ret = ttm_bo_validate(bo, placement, interruptible, false);
- if (!resv)
+ if (!resv) {
ttm_bo_unreserve(bo);
+ } else if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
+ spin_lock(&bo->glob->lru_lock);
+ ttm_bo_add_to_lru(bo);
+ spin_unlock(&bo->glob->lru_lock);
+ }
+
if (unlikely(ret))
ttm_bo_unref(&bo);
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
