On Tue 27-02-24 18:06:05, Yafang Shao wrote: > On Tue, Feb 27, 2024 at 5:45 PM Michal Hocko <mhocko@xxxxxxxx> wrote: [...] > > > Reclaiming numerous dentries through force_empty can also lead to > > > potential issues, which is why we attempt to shrink the slab gradually > > > to mitigate them. However, it's important to note that the underlying > > > causes of the issues in force_empty and rmdir are not identical, as > > > they involve different locks. > > > > Please be more specific about those issues. > > Both of these issues stem from lock contention: > > - rmdir > When executing rmdir, the lock of the inode of the empty directory is > held. If this directory contains numerous negative dentries, this lock > is held for an extended duration. Consequently, if other processes > attempt to acquire this lock, they are blocked. > A simple reproducer involves: > > 1. Generating numerous negative dentries in an empty directory. > 2. Running `rmdir ~/test` and `ls ~/` concurrently. I fail to see how is this relevant to memcg reclaim > This setup demonstrates that ls takes a significant amount of time to > complete due to lock contention. > > - force_empty > Force_empty holds the lock of super_block->dentry_list. However, I > haven't yet had the opportunity to produce a specific example to > illustrate this issue. OK, get back to us once you can identify an actual problem. We might be talking about different things here though. My question is directed at existing memcg interfaces to reclaim the memory. That would be legacy (and effectively deprecated) force_empty and memory.reclaim that we have. -- Michal Hocko SUSE Labs
