Re: MM global locks as core counts quadruple

[Yafang Shao <laoar.shao@gmail.com>]

On Fri, Jun 21, 2024 at 8:50 AM David Rientjes <rientjes@google.com> wrote:
>
> Hi all,
>
> As core counts are rapidly expanding over the next four years, Namhyung
> and I were looking at global locks that we're already seeing high
> contention on even today.
>
> Some of these are not MM specific:
>  - cgroup_mutex

We previously discussed replacing cgroup_mutex with RCU in some
critical paths [0], but I haven't had the time to implement it yet.

[0]. https://lore.kernel.org/bpf/CALOAHbAgWoFGSc=uF5gFWXmsALECUaGGScQuXpRcwjgzv+TPGQ@mail.gmail.com/

>  - cgroup_threadgroup_rwsem
>  - tasklist_lock
>  - kernfs_mutex (although should now be substantially better with the
>    kernfs_locks array)
>
> Others *are* MM specific:
>  - list_lrus_mutex
>  - pcpu_drain_mutex
>  - shrinker_mutex (formerly shrinker_rwsem)
>  - vmap_purge_lock
>  - slab_mutex
>
> This is only looking at fleet data for global static locks, not locks like
> zone->lock that get dynamically allocated.

We have encountered latency spikes caused by the zone->lock. Do we
have any plans to eliminate this lock, such as implementing a lockless
buddy list? I believe this could be a viable solution.

>
> (mmap_lock was substantially improved by per-vma locking, although does
> show up for very large vmas.)
>
> Couple questions:
>
>  (1) How are people quantifying these pain points, if at all, in synthetic
>      testing?  Any workloads or benchmarks that are really good at doing
>      this in the lab beyond the traditional will-it-scale?  (The above is
>      from production data.)
>
>  (2) Is anybody working on any of the above global locks?  Trying to
>      surface gaps for locks that will likely become even more painful in
>      the coming years.
>
> Thanks!
>


-- 
Regards
Yafang