i915 ttm_tt shmem backend

[Matthew Auld]

On Thu, 9 Sept 2021 at 17:43, Koenig, Christian
<Christian.Koenig at amd.com> wrote:
>
> Hi Matthew,
>
> this doesn't work, I've already tried something similar.
>
> TTM uses the reverse lookup functionality when migrating BOs between system and device memory. And that doesn't seem to work with pages from a shmem file.

Hmm, what do you mean by reverse lookup functionality? Could you
please point out where that is in the TTM code?

>
> Regards,
> Christian.
>
> ________________________________
> Von: Matthew Auld <matthew.william.auld at gmail.com>
> Gesendet: Donnerstag, 9. September 2021 16:56
> An: Christian König <ckoenig.leichtzumerken at gmail.com>; Koenig, Christian <Christian.Koenig at amd.com>
> Cc: Thomas Hellström <thomas.hellstrom at linux.intel.com>; ML dri-devel <dri-devel at lists.freedesktop.org>
> Betreff: i915 ttm_tt shmem backend
>
> Hi Christian,
>
> We are looking into using shmem as a ttm_tt backend in i915 for cached
> system memory objects. We would also like to make such objects visible
> to the i915-gem shrinker, so that they may be swapped out or discarded
> when under memory pressure.
>
> One idea for handling this is roughly something like:
> - Add a new TTM_PAGE_FLAG_SHMEM flag, or similar.
> - Skip the ttm_pages_allocated accounting on such objects, similar to
> how FLAG_SG is already handled.
> - Skip all the page->mapping and page->index related bits, like in
> tt_add_mapping, since it looks like these are set and used by shmem.
> Not sure what functionally this might break, but looks like it's maybe
> only driver specific?
> - Skip calling into ttm_bo_swap_out/in and just have
> ttm_populate/unpopulate handle this directly for such objects.
> - Make such objects visible to the i915-gem shrinker.
>
> Does this approach look acceptable?