On Tue, Dec 15, 2020 at 01:09:57PM +1100, Dave Chinner wrote: > On Mon, Dec 14, 2020 at 02:37:15PM -0800, Yang Shi wrote: > > Since memcg_shrinker_map_size just can be changd under holding shrinker_rwsem > > exclusively, the read side can be protected by holding read lock, so it sounds > > superfluous to have a dedicated mutex. > > I'm not sure this is a good idea. This couples the shrinker > infrastructure to internal details of how cgroups are initialised > and managed. Sure, certain operations might be done in certain > shrinker lock contexts, but that doesn't mean we should share global > locks across otherwise independent subsystems.... They're not independent subsystems. Most of the memory controller is an extension of core VM operations that is fairly difficult to understand outside the context of those operations. Then there are a limited number of entry points from the cgroup interface. We used to have our own locks for core VM structures (private page lock e.g.) to coordinate VM and cgroup, and that was mostly unintelligble. We have since established that those two components coordinate with native VM locking and lifetime management. If you need to lock the page, you lock the page - instead of having all VM paths that already hold the page lock acquire a nested lock to exclude one cgroup path. In this case, we have auxiliary shrinker data, subject to shrinker lifetime and exclusion rules. It's much easier to understand that cgroup creation needs a stable shrinker list (shrinker_rwsem) to manage this data, than having an aliased lock that is private to the memcg callbacks and obscures this real interdependency.
