Re: [External] Re: [PATCH 0/2] Postpone memcg reclaim to return-to-user path
From: Zhongkun He
Date: Tue Jun 24 2025 - 03:46:26 EST
On Thu, Jun 19, 2025 at 4:05 PM Jan Kara <jack@xxxxxxx> wrote:
>
> On Wed 18-06-25 15:37:20, Shakeel Butt wrote:
> > > This is
> > > beneficial for users who perform over-max reclaim while holding multiple
> > > locks or other resources (especially resources related to file system
> > > writeback). If a task needs any of these resources, it would otherwise
> > > have to wait until the other task completes reclaim and releases the
> > > resources. Postponing reclaim to the return-to-user path helps avoid this issue.
> > >
> > > # Background
> > >
> > > We have been encountering an hungtask issue for a long time. Specifically,
> > > when a task holds the jbd2 handler
> >
> > Can you explain a bit more about jbd2 handler? Is it some global shared
> > lock or a workqueue which can only run single thread at a time.
> > Basically is there a way to get the current holder/owner of jbd2 handler
> > programmatically?
>
> There's a typo in the original email :). It should be "jbd2 handle". And
> that is just a reference to the currently running transaction in ext4
> filesystem. There can be always at most one running transaction in ext4
> filesystem and until the last reference is dropped it cannot commit. This
> eventually (once the transaction reaches its maximum size) blocks all the
> other modifications to the filesystem. So it is shared global resource
> that's held by the process doing reclaim.
>
> Since there can be many holders of references to the currently running
> transaction there's no easy way to iterate processes that are holding the
> references... That being said ext4 sets current->journal_info when
> acquiring a journal handle but other filesystems use this field for other
> purposes so current->journal_info being non-NULL does not mean jbd2 handle
> is held.
Hi Jan,
Thanks for your feedback and explanations.
>
> Honza
> --
> Jan Kara <jack@xxxxxxxx>
> SUSE Labs, CR