From: Andrew Morton <akpm@linux-foundation.org>
To: Greg Thelen <gthelen@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] vfs: dcache: cond_resched in shrink_dentry_list
Date: Wed, 10 Apr 2013 16:44:55 -0700 [thread overview]
Message-ID: <20130410164455.a3cbcbdf86bc72455c22f420@linux-foundation.org> (raw)
In-Reply-To: <xr9361zvdxvj.fsf@gthelen.mtv.corp.google.com>
On Tue, 09 Apr 2013 17:37:20 -0700 Greg Thelen <gthelen@google.com> wrote:
> > Call cond_resched() in shrink_dcache_parent() to maintain
> > interactivity.
> >
> > Before this patch:
> >
> > void shrink_dcache_parent(struct dentry * parent)
> > {
> > while ((found = select_parent(parent, &dispose)) != 0)
> > shrink_dentry_list(&dispose);
> > }
> >
> > select_parent() populates the dispose list with dentries which
> > shrink_dentry_list() then deletes. select_parent() carefully uses
> > need_resched() to avoid doing too much work at once. But neither
> > shrink_dcache_parent() nor its called functions call cond_resched().
> > So once need_resched() is set select_parent() will return single
> > dentry dispose list which is then deleted by shrink_dentry_list().
> > This is inefficient when there are a lot of dentry to process. This
> > can cause softlockup and hurts interactivity on non preemptable
> > kernels.
> >
> > This change adds cond_resched() in shrink_dcache_parent(). The
> > benefit of this is that need_resched() is quickly cleared so that
> > future calls to select_parent() are able to efficiently return a big
> > batch of dentry.
> >
> > These additional cond_resched() do not seem to impact performance, at
> > least for the workload below.
> >
> > Here is a program which can cause soft lockup on a if other system
> > activity sets need_resched().
I was unable to guess what word was missing from "on a if other" ;)
> Should this change go through Al's or Andrew's branch?
I'll fight him for it.
Softlockups are fairly serious, so I'll put a cc:stable in there. Or
were the changes which triggered this problem added after 3.9?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Greg Thelen <gthelen@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] vfs: dcache: cond_resched in shrink_dentry_list
Date: Wed, 10 Apr 2013 16:44:55 -0700 [thread overview]
Message-ID: <20130410164455.a3cbcbdf86bc72455c22f420@linux-foundation.org> (raw)
In-Reply-To: <xr9361zvdxvj.fsf@gthelen.mtv.corp.google.com>
On Tue, 09 Apr 2013 17:37:20 -0700 Greg Thelen <gthelen@google.com> wrote:
> > Call cond_resched() in shrink_dcache_parent() to maintain
> > interactivity.
> >
> > Before this patch:
> >
> > void shrink_dcache_parent(struct dentry * parent)
> > {
> > while ((found = select_parent(parent, &dispose)) != 0)
> > shrink_dentry_list(&dispose);
> > }
> >
> > select_parent() populates the dispose list with dentries which
> > shrink_dentry_list() then deletes. select_parent() carefully uses
> > need_resched() to avoid doing too much work at once. But neither
> > shrink_dcache_parent() nor its called functions call cond_resched().
> > So once need_resched() is set select_parent() will return single
> > dentry dispose list which is then deleted by shrink_dentry_list().
> > This is inefficient when there are a lot of dentry to process. This
> > can cause softlockup and hurts interactivity on non preemptable
> > kernels.
> >
> > This change adds cond_resched() in shrink_dcache_parent(). The
> > benefit of this is that need_resched() is quickly cleared so that
> > future calls to select_parent() are able to efficiently return a big
> > batch of dentry.
> >
> > These additional cond_resched() do not seem to impact performance, at
> > least for the workload below.
> >
> > Here is a program which can cause soft lockup on a if other system
> > activity sets need_resched().
I was unable to guess what word was missing from "on a if other" ;)
> Should this change go through Al's or Andrew's branch?
I'll fight him for it.
Softlockups are fairly serious, so I'll put a cc:stable in there. Or
were the changes which triggered this problem added after 3.9?
next prev parent reply other threads:[~2013-04-10 23:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 17:22 [PATCH] vfs: dcache: cond_resched in shrink_dentry_list Greg Thelen
2013-03-25 23:56 ` Dave Chinner
2013-03-26 0:39 ` Greg Thelen
2013-03-26 2:40 ` Dave Chinner
2013-03-26 4:36 ` Greg Thelen
2013-04-10 0:37 ` Greg Thelen
2013-04-10 0:37 ` Greg Thelen
2013-04-10 23:44 ` Andrew Morton [this message]
2013-04-10 23:44 ` Andrew Morton
2013-04-11 0:15 ` Greg Thelen
2013-04-11 0:15 ` Greg Thelen
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=20130410164455.a3cbcbdf86bc72455c22f420@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=gthelen@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.