New series based on the discussion in the previous thread around getting lock_page_memcg() out of rmap. I beat on this with concurrent high-frequency moving of tasks that partially share a swapped out shmem file. I didn't spot anything problematic. That said, it is quite subtle, and Hugh, I'd feel better if you could also subject it to your torture suite ;) Thanks! Against yesterday's mm-unstable. Documentation/admin-guide/cgroup-v1/memory.rst | 11 ++++- mm/memcontrol.c | 56 ++++++++++++++++++------ mm/rmap.c | 26 ++++------- 3 files changed, 60 insertions(+), 33 deletions(-)
