[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

On Mon, Jan 11, 2016 at 04:54:19PM +0100, Christian König wrote: > >Out of curiosity, where do you generate so many foreign dma-buf backes > >objects? > That was just an experiment of sharing buffers between two AMD devices. A > stupid reference count bug and I've leaked 60 full HD frame a second.

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

> Out of curiosity, where do you generate so many foreign dma-buf backes > objects? That was just an experiment of sharing buffers between two AMD devices. A stupid reference count bug and I've leaked 60 full HD frame a second. Took a bit over two minutes to eat up 1GB of GTT space and the box dy

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

On Mon, Jan 11, 2016 at 03:38:23PM +0100, Christian König wrote: > >While this would be one way to work around the GTT space DOS, it > >wouldn't work around the DOS problem of the exporter pinning system > >pages that probably never get accounted. That's a limitation of the > >export-import mechan

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

> While this would be one way to work around the GTT space DOS, it > wouldn't work around the DOS problem of the exporter pinning system > pages that probably never get accounted. That's a limitation of the > export-import mechanism (dma-buf). Yeah, completely agree. That's a problem we sooner or

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

On 01/11/2016 01:39 PM, Christian König wrote: > Am 10.01.2016 um 16:10 schrieb Thomas Hellstrom: >> On 01/09/2016 11:46 AM, Christian König wrote: >>> 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 impo

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

Am 10.01.2016 um 16:10 schrieb Thomas Hellstrom: > On 01/09/2016 11:46 AM, Christian König wrote: >> 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 sh

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

On 2016年01月10日 23:10, Thomas Hellstrom wrote: > On 01/09/2016 11:46 AM, Christian König wrote: >> 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 obje

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

On 01/09/2016 11:46 AM, Christian König wrote: > 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 wo

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

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

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

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

[PATCH] drm/ttm: fix adding foreign BOs to the LRU during init

From: Christian König 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 --- drivers/gpu/drm/ttm/ttm_bo.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletio