On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable update the shrinker visible lists immediately. This at least simplifies the next patch, and does make the behaviour more obvious. The potential downside is that make_unshrinkable now grabs a global lock even when the object itself is no longer shrinkable(transitioning from purgeable <-
shrinkable doesn't seem to be a thing), for example in the ppGTT insertion paths we should now be careful not to needlessly call make_unshrinkable multiple times. Outside of that there is some fallout in intel_context which relies on nesting calls to shrink_pin.
Signed-off-by: Matthew Auld matthew.auld@intel.com Cc: Thomas Hellström thomas.hellstrom@linux.intel.com
Hmm. One thing that worries me a bit here: Let's say we have, for example an LMEM context state, and TTM has it made unshrinkable. Then the context becomes active and calls _make_unshrinkable again. And when it retires it callse _make_shrinkable. Doesn't it end up on the shrinker list at that point, even if still in LMEM?
/Thomas