Re: [PATCH 0/2] Postpone memcg reclaim to return-to-user path

[Jan Kara <jack@suse.cz>]

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.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR