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.
Regards,
Christian.
Von: Matthew Auld <matthew.william.auld@xxxxxxxxx>
Gesendet: Donnerstag, 9. September 2021 16:56
An: Christian König <ckoenig.leichtzumerken@xxxxxxxxx>; Koenig, Christian <Christian.Koenig@xxxxxxx>
Cc: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>; ML dri-devel <dri-devel@xxxxxxxxxxxxxxxxxxxxx>
Betreff: i915 ttm_tt shmem backend
Gesendet: Donnerstag, 9. September 2021 16:56
An: Christian König <ckoenig.leichtzumerken@xxxxxxxxx>; Koenig, Christian <Christian.Koenig@xxxxxxx>
Cc: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>; ML dri-devel <dri-devel@xxxxxxxxxxxxxxxxxxxxx>
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?
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?
