Hi, all On Tue, 2024-05-21 at 09:16 +0200, Thomas Hellström wrote: > This series implements TTM shrinker / eviction helpers and an xe bo > shrinker. It builds on two previous series, *and obsoletes these*. > First > > https://www.mail-archive.com/dri-devel@xxxxxxxxxxxxxxxxxxxxx/msg484425.html > > Second the previous TTM shrinker series > > https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2d67@xxxxxxx/T/ > > Where the comment about layering > https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2d67@xxxxxxx/T/#ma918844aa8a6efe8768fdcda0c6590d5c93850c9 > > now addressed, and this version also implements shmem objects for > backup > rather than direct swap-cache insertions, which was used in the > previuos > series. It turns out that with per-page backup / shrinking, shmem > objects > appears to work just as well as direct swap-cache insertions with the > added benefit that was introduced in the previous TTM shrinker series > to > avoid running out of swap entries isn't really needed. > > Patch 1-4 implements restartable LRU list iteration. > > Patch 5 implements a LRU walker + resv locking helper > > Patch 6 moves TTM swapping over to the walker. > > Patch 7 moves TTM eviction over to the walker. > > Patch 8 could in theory be skipped but introduces a possibility to > easily > add or test multiple backup backends, like the direct swap-cache > insertion or even files into fast dedicated nvme storage for for > example. > > Patch 9 introduces helpers in the ttm_pool code for page-by-page > shrinking > and recovery. It avoids having to temporarily allocate a huge amount > of > memory to be able to shrink a buffer object. It also introduces the > possibility to immediately write-back pages if needed, since that > tends > to be a bit delayed when left to kswapd. > > Patch 10 Adds a simple error injection to the above code to help > increase > test coverage. > > Patch 11 Implements an xe bo shrinker and a common helper in TTM for > shrinking. > > Patch 12-21 are really a separate POC series, for introducing > drm_exec locking > in TTM. The patch touches both drm_exec and dma-buf and is for now > marked as > an RFC: > > Patch 12 Introduces dma_resv_trylock_ctx. > > Patches 13-14 deal with introducing drm_exec_trylock. > > Patch 15 adds a snapshot capability to drm_exec. > > Patch 16 adds an evict mode locking capability to drm_exec > > Patch 17 converts the LRU + locking walker to drm_exec. > > Patch 18 converts TTM vm to use drm_exec. > > Patch 19 converts the xe fault handler to drm_exec. > > Patch 20 converts bo initialization locking to drm_exec > > Patch 21 introduces drm_exec locking around some of the > bo validation callsites in drm_exec. > > v2: > - Squash obsolete revision history in the patch commit messages. > - Fix a couple of review comments by Christian > - Don't store the mem_type in the TTM managers but in the > resource cursor. > - Rename introduced TTM *back_up* function names to *backup* > - Add ttm pool recovery fault injection. > - Shrinker xe kunit test > - Various bugfixes > > v3: > - Address some review comments from Matthew Brost and Christian > König. > - Use the restartable LRU walk for TTM swapping and eviction. > - Provide a POC drm_exec locking implementation for exhaustive > eviction. (Christian König). > > Cc: Somalapuram Amaranath <Amaranath.Somalapuram@xxxxxxx> > Cc: Christian König <christian.koenig@xxxxxxx> > Cc: Matthew Brost <matthew.brost@xxxxxxxxx> > Cc: <dri-devel@xxxxxxxxxxxxxxxxxxxxx> Now with a POC available how the drm_exec locking could be done in TTM (the RFC part) I think the best approach is to get patch 1-11 reviewed and pushed, and we could then settle on a solution for the drm_exec part as a follow-up. Undoubtedly there are a couple of things that need discussion there, in particular the resv_set, the snapshot and the trylock memory allocation. /Thomas
