Re: [RFC PATCH] mm: Add reclaim type to memory.reclaim

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

On Tue, Feb 27, 2024 at 10:03 PM Yafang Shao <laoar.shao@gmail.com> wrote:
>
> On Tue, Feb 27, 2024 at 9:20 PM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Tue 27-02-24 18:06:05, Yafang Shao wrote:
> > > On Tue, Feb 27, 2024 at 5:45 PM Michal Hocko <mhocko@suse.com> 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
>
>
> It appears there might still be some misunderstanding regarding the
> issue at hand.
>
> The numerous negative dentries are generated within a memcg. I
> simplified the explanation by omitting the memcg context.
>
> >
> > > 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
>
> Pls. take a look at the force_empty->prune_dcache_sb->shrink_dentry_list.

Please note that the spinlock is located within list_lru_walk_one.
Additionally, the issue persists even with the newly introduced
memory.reclaim, as it functions similarly to force_empty.

>
> > 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.
>
>
>
> --
> Regards
> Yafang



-- 
Regards
Yafang