All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Jan Kara <jack@suse.cz>
Cc: Tejun Heo <tj@kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Dennis Zhou <dennis@kernel.org>,
	Dave Chinner <dchinner@redhat.com>, <cgroups@vger.kernel.org>
Subject: Re: [PATCH v5 1/2] writeback, cgroup: keep list of inodes attached to bdi_writeback
Date: Thu, 27 May 2021 09:32:57 -0700	[thread overview]
Message-ID: <YK/JueoCO4LisjDo@carbon.DHCP.thefacebook.com> (raw)
In-Reply-To: <20210527103517.GA24486@quack2.suse.cz>

On Thu, May 27, 2021 at 12:35:17PM +0200, Jan Kara wrote:
> On Wed 26-05-21 15:25:56, Roman Gushchin wrote:
> > Currently there is no way to iterate over inodes attached to a
> > specific cgwb structure. It limits the ability to efficiently
> > reclaim the writeback structure itself and associated memory and
> > block cgroup structures without scanning all inodes belonging to a sb,
> > which can be prohibitively expensive.
> > 
> > While dirty/in-active-writeback an inode belongs to one of the
> > bdi_writeback's io lists: b_dirty, b_io, b_more_io and b_dirty_time.
> > Once cleaned up, it's removed from all io lists. So the
> > inode->i_io_list can be reused to maintain the list of inodes,
> > attached to a bdi_writeback structure.
> > 
> > This patch introduces a new wb->b_attached list, which contains all
> > inodes which were dirty at least once and are attached to the given
> > cgwb. Inodes attached to the root bdi_writeback structures are never
> > placed on such list. The following patch will use this list to try to
> > release cgwbs structures more efficiently.
> > 
> > Suggested-by: Jan Kara <jack@suse.cz>
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> 
> Looks good. Just some minor nits below:
> 
> > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > index e91980f49388..631ef6366293 100644
> > --- a/fs/fs-writeback.c
> > +++ b/fs/fs-writeback.c
> > @@ -135,18 +135,23 @@ static bool inode_io_list_move_locked(struct inode *inode,
> >   * inode_io_list_del_locked - remove an inode from its bdi_writeback IO list
> >   * @inode: inode to be removed
> >   * @wb: bdi_writeback @inode is being removed from
> > + * @final: inode is going to be freed and can't reappear on any IO list
> >   *
> >   * Remove @inode which may be on one of @wb->b_{dirty|io|more_io} lists and
> >   * clear %WB_has_dirty_io if all are empty afterwards.
> >   */
> >  static void inode_io_list_del_locked(struct inode *inode,
> > -				     struct bdi_writeback *wb)
> > +				     struct bdi_writeback *wb,
> > +				     bool final)
> >  {
> >  	assert_spin_locked(&wb->list_lock);
> >  	assert_spin_locked(&inode->i_lock);
> >  
> >  	inode->i_state &= ~I_SYNC_QUEUED;
> > -	list_del_init(&inode->i_io_list);
> > +	if (final)
> > +		list_del_init(&inode->i_io_list);
> > +	else
> > +		inode_cgwb_move_to_attached(inode, wb);
> >  	wb_io_lists_depopulated(wb);
> >  }
> 
> With these changes the naming is actually somewhat confusing and the bool
> argument makes it even worse. Looking into the code I'd just fold
> inode_io_list_del_locked() into inode_io_list_del() and make it really
> delete inode from all IO lists. There are currently three other
> inode_io_list_del_locked() users:

Yeah, good idea. Will do in the next version. Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
To: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	Alexander Viro
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Dennis Zhou <dennis-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Dave Chinner <dchinner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v5 1/2] writeback, cgroup: keep list of inodes attached to bdi_writeback
Date: Thu, 27 May 2021 09:32:57 -0700	[thread overview]
Message-ID: <YK/JueoCO4LisjDo@carbon.DHCP.thefacebook.com> (raw)
In-Reply-To: <20210527103517.GA24486-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>

On Thu, May 27, 2021 at 12:35:17PM +0200, Jan Kara wrote:
> On Wed 26-05-21 15:25:56, Roman Gushchin wrote:
> > Currently there is no way to iterate over inodes attached to a
> > specific cgwb structure. It limits the ability to efficiently
> > reclaim the writeback structure itself and associated memory and
> > block cgroup structures without scanning all inodes belonging to a sb,
> > which can be prohibitively expensive.
> > 
> > While dirty/in-active-writeback an inode belongs to one of the
> > bdi_writeback's io lists: b_dirty, b_io, b_more_io and b_dirty_time.
> > Once cleaned up, it's removed from all io lists. So the
> > inode->i_io_list can be reused to maintain the list of inodes,
> > attached to a bdi_writeback structure.
> > 
> > This patch introduces a new wb->b_attached list, which contains all
> > inodes which were dirty at least once and are attached to the given
> > cgwb. Inodes attached to the root bdi_writeback structures are never
> > placed on such list. The following patch will use this list to try to
> > release cgwbs structures more efficiently.
> > 
> > Suggested-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> > Signed-off-by: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
> 
> Looks good. Just some minor nits below:
> 
> > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > index e91980f49388..631ef6366293 100644
> > --- a/fs/fs-writeback.c
> > +++ b/fs/fs-writeback.c
> > @@ -135,18 +135,23 @@ static bool inode_io_list_move_locked(struct inode *inode,
> >   * inode_io_list_del_locked - remove an inode from its bdi_writeback IO list
> >   * @inode: inode to be removed
> >   * @wb: bdi_writeback @inode is being removed from
> > + * @final: inode is going to be freed and can't reappear on any IO list
> >   *
> >   * Remove @inode which may be on one of @wb->b_{dirty|io|more_io} lists and
> >   * clear %WB_has_dirty_io if all are empty afterwards.
> >   */
> >  static void inode_io_list_del_locked(struct inode *inode,
> > -				     struct bdi_writeback *wb)
> > +				     struct bdi_writeback *wb,
> > +				     bool final)
> >  {
> >  	assert_spin_locked(&wb->list_lock);
> >  	assert_spin_locked(&inode->i_lock);
> >  
> >  	inode->i_state &= ~I_SYNC_QUEUED;
> > -	list_del_init(&inode->i_io_list);
> > +	if (final)
> > +		list_del_init(&inode->i_io_list);
> > +	else
> > +		inode_cgwb_move_to_attached(inode, wb);
> >  	wb_io_lists_depopulated(wb);
> >  }
> 
> With these changes the naming is actually somewhat confusing and the bool
> argument makes it even worse. Looking into the code I'd just fold
> inode_io_list_del_locked() into inode_io_list_del() and make it really
> delete inode from all IO lists. There are currently three other
> inode_io_list_del_locked() users:

Yeah, good idea. Will do in the next version. Thanks!

  reply	other threads:[~2021-05-27 16:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26 22:25 [PATCH v5 0/2] cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups Roman Gushchin
2021-05-26 22:25 ` Roman Gushchin
2021-05-26 22:25 ` [PATCH v5 1/2] writeback, cgroup: keep list of inodes attached to bdi_writeback Roman Gushchin
2021-05-26 22:25   ` Roman Gushchin
2021-05-27 10:35   ` Jan Kara
2021-05-27 10:35     ` Jan Kara
2021-05-27 16:32     ` Roman Gushchin [this message]
2021-05-27 16:32       ` Roman Gushchin
2021-05-26 22:25 ` [PATCH v5 2/2] writeback, cgroup: release dying cgwbs by switching attached inodes Roman Gushchin
2021-05-26 22:25   ` Roman Gushchin
2021-05-27  3:24   ` Hillf Danton
2021-05-27 16:29     ` Roman Gushchin
2021-05-27 16:29       ` Roman Gushchin
2021-05-27 11:24   ` Jan Kara
2021-05-27 11:24     ` Jan Kara
2021-05-27 17:48     ` Roman Gushchin
2021-05-27 17:48       ` Roman Gushchin
2021-05-27 19:45       ` Roman Gushchin
2021-05-27 19:45         ` Roman Gushchin
2021-05-28 13:05       ` Jan Kara
2021-05-28 13:05         ` Jan Kara
2021-05-28 16:25         ` Roman Gushchin
2021-05-28 16:25           ` Roman Gushchin
2021-05-28  2:58   ` Ming Lei
2021-05-28 16:22     ` Roman Gushchin
2021-05-28 16:22       ` Roman Gushchin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YK/JueoCO4LisjDo@carbon.DHCP.thefacebook.com \
    --to=guro@fb.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dchinner@redhat.com \
    --cc=dennis@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tj@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.