From: Josef Bacik <jbacik@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jbacik@redhat.com, Alexey.Lyashkov@Sun.COM,
linux-fsdevel@vger.kernel.org, Andrew.Perepechko@Sun.COM,
dhowells@redhat.com
Subject: Re: [RFC] possible badness in prune_dcache()
Date: Fri, 4 Apr 2008 14:44:08 -0400 [thread overview]
Message-ID: <20080404184408.GG22429@unused.rdu.redhat.com> (raw)
In-Reply-To: <E1Jhqo3-0003WF-99@pomaz-ex.szeredi.hu>
On Fri, Apr 04, 2008 at 08:38:31PM +0200, Miklos Szeredi wrote:
> > > probably worth looking at doing something different in the case of
> > > shrinking the dcache on the parent, and leaving prune_dcache to
> > > only be called in the case of trying to free up dcache under
> > > memory pressure, where the superblock doesn't actually matter.
> > > For the RHEL3 issue you are reffering to I fixed it by creating a
> > > private list when we shrunk the parent, and submitting that list
> > > to prune_dcache that way we didn't spend all this time looping. I
> > > will see what can be done for upstream.
>
> Which sounds racy with umount. A hashed dentry must either have a
> refcount greater than one, or be on dentry_unused list. This patch
> breaks that assumption.
>
It should be racy with umount, if we notice that we're being unmounted we just
break, as the unmount will free the dentry's itself through another means. I
guess I could fix it so that prune_dcache will go through and add all the
dentry's still on the dispose_list to the dentry_unused list at the end, but I
don't see much of a reason for this since dentry_unused is just used to help
keep track of what dentries can be flushed.
Josef
next prev parent reply other threads:[~2008-04-04 18:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-04 11:40 [RFC] possible badness in prune_dcache() Alex Lyashkov
2008-04-04 12:42 ` Miklos Szeredi
2008-04-04 15:28 ` Alex Lyashkov
2008-04-04 15:29 ` Josef Bacik
2008-04-04 15:57 ` Josef Bacik
2008-04-04 18:38 ` Miklos Szeredi
2008-04-04 18:44 ` Josef Bacik [this message]
2008-04-04 18:49 ` Josef Bacik
2008-04-04 19:01 ` Miklos Szeredi
2008-04-04 19:13 ` Josef Bacik
2008-04-04 19:32 ` Miklos Szeredi
2008-04-07 6:40 ` Takashi Nishiie
2008-04-07 10:49 ` David Howells
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=20080404184408.GG22429@unused.rdu.redhat.com \
--to=jbacik@redhat.com \
--cc=Alexey.Lyashkov@Sun.COM \
--cc=Andrew.Perepechko@Sun.COM \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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.