From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Tobin C. Harding" <tobin@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <guro@fb.com>,
Alexander Viro <viro@ftp.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Christopher Lameter <cl@linux.com>,
Matthew Wilcox <willy@infradead.org>,
Miklos Szeredi <mszeredi@redhat.com>,
Andreas Dilger <adilger@dilger.ca>,
Waiman Long <longman@redhat.com>, Tycho Andersen <tycho@tycho.ws>,
Theodore Ts'o <tytso@mit.edu>, Andi Kleen <ak@linux.intel.com>,
David Chinner <david@fromorbit.com>,
Nick Piggin <npiggin@gmail.com>, Rik van Riel <riel@redhat.com>,
Hugh Dickins <hughd@google.com>, Jonathan Corbet <corbet@lwn.net>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: shrink_dentry_list() logics change (was Re: [RFC PATCH v3 14/15] dcache: Implement partial shrink via Slab Movable Objects)
Date: Sat, 29 Jun 2019 20:06:24 +0100 [thread overview]
Message-ID: <20190629190624.GU17978@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190629043803.GT17978@ZenIV.linux.org.uk>
On Sat, Jun 29, 2019 at 05:38:03AM +0100, Al Viro wrote:
> PS: the problem is not gone in the next iteration of the patchset in
> question. The patch I'm proposing (including dput_to_list() and _ONLY_
> compile-tested) follows. Comments?
FWIW, there's another unpleasantness in the whole thing. Suppose we have
picked a page full of dentries, all with refcount 0. We decide to
evict all of them. As it turns out, they are from two filesystems.
Filesystem 1 is NFS on a server, with currently downed hub on the way
to it. Filesystem 2 is local. We attempt to evict an NFS dentry and
get stuck - tons of dirty data with no way to flush them on server.
In the meanwhile, admin tries to unmount the local filesystem. And
gets stuck as well, since umount can't do anything to its dentries
that happen to sit in our shrink list.
I wonder if the root of problem here isn't in shrink_dcache_for_umount();
all it really needs is to have everything on that fs with refcount 0
dragged through __dentry_kill(). If something had been on a shrink
list, __dentry_kill() will just leave behind a struct dentry completely
devoid of any connection to superblock, other dentries, filesystem
type, etc. - it's just a piece of memory that won't be freed until
the owner of shrink list finally gets around to it. Which can happen
at any point - all they'll do to it is dentry_free(), and that doesn't
need any fs-related data structures.
The logics in shrink_dcache_parent() is
collect everything evictable into a shrink list
if anything found - kick it out and repeat the scan
otherwise, if something had been on other's shrink list
repeat the scan
I wonder if after the "no evictable candidates, but something
on other's shrink lists" we ought to do something along the
lines of
rcu_read_lock
walk it, doing
if dentry has zero refcount
if it's not on a shrink list,
move it to ours
else
store its address in 'victim'
end the walk
if no victim found
rcu_read_unlock
else
lock victim for __dentry_kill
rcu_read_unlock
if it's still alive
if it's not IS_ROOT
if parent is not on shrink list
decrement parent's refcount
put it on our list
else
decrement parent's refcount
__dentry_kill(victim)
else
unlock
if our list is non-empty
shrink_dentry_list on it
in there...
next prev parent reply other threads:[~2019-06-29 19:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 1:34 [RFC PATCH v3 00/15] Slab Movable Objects (SMO) Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 01/15] slub: Add isolate() and migrate() methods Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 02/15] tools/vm/slabinfo: Add support for -C and -M options Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 03/15] slub: Sort slab cache list Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 04/15] slub: Slab defrag core Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 05/15] tools/vm/slabinfo: Add remote node defrag ratio output Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 06/15] tools/vm/slabinfo: Add defrag_used_ratio output Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 07/15] tools/testing/slab: Add object migration test module Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 08/15] tools/testing/slab: Add object migration test suite Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 09/15] xarray: Implement migration function for objects Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 10/15] tools/testing/slab: Add XArray movable objects tests Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 11/15] slub: Enable moving objects to/from specific nodes Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 12/15] slub: Enable balancing slabs across nodes Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 13/15] dcache: Provide a dentry constructor Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 14/15] dcache: Implement partial shrink via Slab Movable Objects Tobin C. Harding
2019-04-11 2:33 ` Al Viro
2019-04-11 2:48 ` Tobin C. Harding
2019-04-11 4:47 ` Al Viro
2019-04-11 5:05 ` Tobin C. Harding
2019-04-11 20:01 ` Al Viro
2019-04-11 21:02 ` Al Viro
2019-06-29 4:08 ` Al Viro
2019-06-29 4:38 ` shrink_dentry_list() logics change (was Re: [RFC PATCH v3 14/15] dcache: Implement partial shrink via Slab Movable Objects) Al Viro
2019-06-29 19:06 ` Al Viro [this message]
2019-06-29 22:29 ` Al Viro
2019-06-29 22:34 ` Al Viro
2019-07-01 9:26 ` Tobin C. Harding
2019-04-11 1:34 ` [RFC PATCH v3 15/15] dcache: Add CONFIG_DCACHE_SMO Tobin C. Harding
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=20190629190624.GU17978@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adilger@dilger.ca \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=david@fromorbit.com \
--cc=guro@fb.com \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mszeredi@redhat.com \
--cc=npiggin@gmail.com \
--cc=penberg@cs.helsinki.fi \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=tobin@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tycho@tycho.ws \
--cc=tytso@mit.edu \
--cc=viro@ftp.linux.org.uk \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).