On Thu, 9 Sept 2021 at 17:43, Koenig, Christian <christian.koe...@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.a...@gmail.com> > Gesendet: Donnerstag, 9. September 2021 16:56 > An: Christian König <ckoenig.leichtzumer...@gmail.com>; Koenig, Christian > <christian.koe...@amd.com> > Cc: Thomas Hellström <thomas.hellst...@linux.intel.com>; ML dri-devel > <dri-devel@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?
