All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Theodore Ts'o <tytso@mit.edu>,
	linux-ext4@vger.kernel.org, Zheng Liu <wenqing.lz@taobao.com>
Subject: Re: [PATCH 7/7 v2] ext4: reclaim extents from extent status tree
Date: Mon, 21 Jan 2013 23:12:36 +0800	[thread overview]
Message-ID: <20130121151236.GA15371@gmail.com> (raw)
In-Reply-To: <20130121144336.GK5588@quack.suse.cz>

On Mon, Jan 21, 2013 at 03:43:36PM +0100, Jan Kara wrote:
> On Fri 18-01-13 00:39:47, Ted Tso wrote:
> > On Fri, Jan 18, 2013 at 12:19:21AM -0500, Theodore Ts'o wrote:
> > > I'm a bit concerned we might be too aggressive,
> > > because there are two ways that items can be freed from the
> > > extent_status tree.  One is if the inode is not used at all, and when
> > > we release the inode, we'll drop all of the entries in the
> > > extent_status_tree for that inode.  The second way is via the shrinker
> > > which we've registered.
> > 
> > If we use the sb->s_op->free_cached_objects() approach, something like
> > the following change to prune_super() in fs/super.c might address the
> > above concern:
>   Yeah, this would make sence to me. When you submit the final patch don't
> forget to include Dave Chinner. He's the author of the shrinker framework
> and XFS uses nr_cached_objects / free_cached_objects. AFAICS it uses it for
> its separate inode cache so your change shouldn't affect it but better be
> sure.

Thanks for reminding.  This patch has been added in my patch series, and
I will CC' it to Dave.

Regards,
                                                - Zheng

> > 
> > diff --git a/fs/super.c b/fs/super.c
> > index 12f1237..fb57bd2 100644
> > --- a/fs/super.c
> > +++ b/fs/super.c
> > @@ -80,6 +80,7 @@ static int prune_super(struct shrinker *shrink, struct shrink_control *sc)
> >  	if (sc->nr_to_scan) {
> >  		int	dentries;
> >  		int	inodes;
> > +		int	fs_to_scan = 0;
> >  
> >  		/* proportion the scan between the caches */
> >  		dentries = (sc->nr_to_scan * sb->s_nr_dentry_unused) /
> > @@ -87,7 +88,7 @@ static int prune_super(struct shrinker *shrink, struct shrink_control *sc)
> >  		inodes = (sc->nr_to_scan * sb->s_nr_inodes_unused) /
> >  							total_objects;
> >  		if (fs_objects)
> > -			fs_objects = (sc->nr_to_scan * fs_objects) /
> > +			fs_to_scan = (sc->nr_to_scan * fs_objects) /
> >  							total_objects;
> >  		/*
> >  		 * prune the dcache first as the icache is pinned by it, then
> > @@ -96,8 +97,23 @@ static int prune_super(struct shrinker *shrink, struct shrink_control *sc)
> >  		prune_dcache_sb(sb, dentries);
> >  		prune_icache_sb(sb, inodes);
> >  
> > -		if (fs_objects && sb->s_op->free_cached_objects) {
> > -			sb->s_op->free_cached_objects(sb, fs_objects);
> > +		/*
> > +		 * If as a result of pruning the icache, we released some
> > +		 * of the fs_objects, give credit to the fact and
> > +		 * reduce the number of fs objects that we should try
> > +		 * to release.
> > +		 */
> > +		if (fs_to_scan) {
> > +			int fs_objects_now = sb->s_op->nr_cached_objects(sb);
> > +
> > +			if (fs_objects_now < fs_objects)
> > +				fs_to_scan -= fs_objects - fs_objects_now;
> > +			if (fs_to_scan < 0)
> > +				fs_to_scan = 0;
> > +		}
> > +
> > +		if (fs_to_scan && sb->s_op->free_cached_objects) {
> > +			sb->s_op->free_cached_objects(sb, fs_to_scan);
> >  			fs_objects = sb->s_op->nr_cached_objects(sb);
> >  		}
> >  		total_objects = sb->s_nr_dentry_unused +
> > 
> > What do folks think?
> > 
> > 						- Ted
> -- 
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR

      reply	other threads:[~2013-01-21 14:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-11 10:53 [PATCH 0/7 v2] ext4: extent status tree (step2) Zheng Liu
2013-01-11 10:53 ` [PATCH 1/7 v2] ext4: refine extent status tree Zheng Liu
2013-01-23  4:20   ` Theodore Ts'o
2013-01-11 10:53 ` [PATCH 2/7 v2] ext4: remove EXT4_MAP_FROM_CLUSTER flag Zheng Liu
2013-01-11 10:53 ` [PATCH 3/7 v2] ext4: add physical block and status member into extent status tree Zheng Liu
2013-01-17  4:42   ` Theodore Ts'o
2013-01-18  9:49     ` Zheng Liu
2013-01-11 10:53 ` [PATCH 4/7 v2] ext4: adjust interfaces of " Zheng Liu
2013-01-11 10:53 ` [PATCH 5/7 v2] ext4: track all extent status in " Zheng Liu
2013-01-23  4:31   ` Theodore Ts'o
2013-01-11 10:53 ` [PATCH 6/7 v2] ext4: lookup block mapping " Zheng Liu
2013-01-18  4:00   ` Theodore Ts'o
2013-01-18  9:52     ` Zheng Liu
2013-01-11 10:53 ` [PATCH 7/7 v2] ext4: reclaim extents from " Zheng Liu
2013-01-18  5:19   ` Theodore Ts'o
2013-01-18  5:39     ` Theodore Ts'o
2013-01-21  7:24       ` Zheng Liu
2013-01-21 15:00         ` Theodore Ts'o
2013-01-21 17:09           ` Zheng Liu
2013-01-23  6:06             ` [PATCH] fs: allow for fs-specific objects to be pruned as part of pruning inodes Theodore Ts'o
2013-01-23 10:52               ` Jan Kara
2013-01-23 13:06               ` Carlos Maiolino
2013-01-23 13:32               ` Dave Chinner
2013-01-23 16:34                 ` Theodore Ts'o
2013-01-23 23:35                   ` Dave Chinner
2013-01-24  8:58                 ` Andrew Morton
2013-01-24 20:03                   ` Dave Chinner
2013-01-21 14:43       ` [PATCH 7/7 v2] ext4: reclaim extents from extent status tree Jan Kara
2013-01-21 15:12         ` Zheng Liu [this message]

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=20130121151236.GA15371@gmail.com \
    --to=gnehzuil.liu@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=wenqing.lz@taobao.com \
    /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.