On Thu, 9 Sept 2021 at 17:43, Koenig, Christian <Christian.Koenig@xxxxxxx> 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@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 > > 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?
