From: Dave Chinner <david@fromorbit.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: stable@kernel.org, John Hawley <warthog9@kernel.org>,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [patch] xfs: properly account for reclaimed inodes
Date: Sat, 2 Oct 2010 00:02:37 +1000 [thread overview]
Message-ID: <20101001140237.GC4681@dastard> (raw)
In-Reply-To: <20101001074354.GF2618@cmpxchg.org>
On Fri, Oct 01, 2010 at 09:43:54AM +0200, Johannes Weiner wrote:
> When marking an inode reclaimable, a per-AG counter is increased, the
> inode is tagged reclaimable in its per-AG tree, and, when this is the
> first reclaimable inode in the AG, the AG entry in the per-mount tree
> is also tagged.
>
> When an inode is finally reclaimed, however, it is only deleted from
> the per-AG tree. Neither the counter is decreased, nor is the parent
> tree's AG entry untagged properly.
>
> Since the tags in the per-mount tree are not cleared, the inode
> shrinker iterates over all AGs that have had reclaimable inodes at one
> point in time.
>
> The counters on the other hand signal an increasing amount of slab
> objects to reclaim. Since "70e60ce xfs: convert inode shrinker to
> per-filesystem context" this is not a real issue anymore because the
> shrinker bails out after one iteration.
>
> But the problem was observable on a machine running v2.6.34, where the
> reclaimable work increased and each process going into direct reclaim
> eventually got stuck on the xfs inode shrinking path, trying to scan
> several million objects.
>
> Fix this by properly unwinding the reclaimable-state tracking of an
> inode when it is reclaimed.
>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Cc: stable@kernel.org
Looks OK to me, and has run through a few hours of testing without
problems.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: xfs@oss.sgi.com, John Hawley <warthog9@kernel.org>,
linux-kernel@vger.kernel.org, stable@kernel.org
Subject: Re: [patch] xfs: properly account for reclaimed inodes
Date: Sat, 2 Oct 2010 00:02:37 +1000 [thread overview]
Message-ID: <20101001140237.GC4681@dastard> (raw)
In-Reply-To: <20101001074354.GF2618@cmpxchg.org>
On Fri, Oct 01, 2010 at 09:43:54AM +0200, Johannes Weiner wrote:
> When marking an inode reclaimable, a per-AG counter is increased, the
> inode is tagged reclaimable in its per-AG tree, and, when this is the
> first reclaimable inode in the AG, the AG entry in the per-mount tree
> is also tagged.
>
> When an inode is finally reclaimed, however, it is only deleted from
> the per-AG tree. Neither the counter is decreased, nor is the parent
> tree's AG entry untagged properly.
>
> Since the tags in the per-mount tree are not cleared, the inode
> shrinker iterates over all AGs that have had reclaimable inodes at one
> point in time.
>
> The counters on the other hand signal an increasing amount of slab
> objects to reclaim. Since "70e60ce xfs: convert inode shrinker to
> per-filesystem context" this is not a real issue anymore because the
> shrinker bails out after one iteration.
>
> But the problem was observable on a machine running v2.6.34, where the
> reclaimable work increased and each process going into direct reclaim
> eventually got stuck on the xfs inode shrinking path, trying to scan
> several million objects.
>
> Fix this by properly unwinding the reclaimable-state tracking of an
> inode when it is reclaimed.
>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Cc: stable@kernel.org
Looks OK to me, and has run through a few hours of testing without
problems.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-10-01 14:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-01 7:43 [patch] xfs: properly account for reclaimed inodes Johannes Weiner
2010-10-01 7:43 ` Johannes Weiner
2010-10-01 14:02 ` Dave Chinner [this message]
2010-10-01 14:02 ` Dave Chinner
2010-10-01 17:17 ` Alex Elder
2010-10-01 17:17 ` Alex Elder
2010-10-04 7:19 ` Dave Chinner
2010-10-04 7:19 ` Dave Chinner
2010-10-04 10:22 ` Johannes Weiner
2010-10-04 10:22 ` Johannes Weiner
2010-10-05 9:26 ` Hans-Peter Jansen
2010-10-05 9:26 ` Hans-Peter Jansen
2010-10-07 3:12 ` Alex Elder
2010-10-07 3:12 ` Alex Elder
2010-10-06 4:53 ` Dave Chinner
2010-10-06 4:53 ` Dave Chinner
2010-10-06 23:46 ` J.H.
2010-10-06 23:46 ` J.H.
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=20101001140237.GC4681@dastard \
--to=david@fromorbit.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@kernel.org \
--cc=warthog9@kernel.org \
--cc=xfs@oss.sgi.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.