From: Al Viro <viro@zeniv.linux.org.uk>
To: Christopher Lameter <cl@linux.com>
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>,
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>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC PATCH v2 14/14] dcache: Implement object migration
Date: Wed, 3 Apr 2019 20:05:20 +0100 [thread overview]
Message-ID: <20190403190520.GW2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190403182454.GU2217@ZenIV.linux.org.uk>
On Wed, Apr 03, 2019 at 07:24:54PM +0100, Al Viro wrote:
> If by "how to do it right" you mean "expedit kicking out something with
> non-zero refcount" - there's no way to do that. Nothing even remotely
> sane.
>
> If you mean "kick out everything in this page with zero refcount" - that
> can be done (see further in the thread).
>
> Look, dentries and inodes are really, really not relocatable. If they
> can be evicted by memory pressure - sure, we can do that for a given
> set (e.g. "everything in that page"). But that's it - if memory
> pressure would _not_ get rid of that one, there's nothing to be done.
> Again, all VM can do is to simulate shrinker hitting hard on given
> bunch (rather than buggering the entire cache). If filesystem (or
> something in VFS) says "it's busy", it bloody well _is_ busy and
> won't be going away until it ceases to be such.
FWIW, some theory: the only kind of long-term reference that can
be killed off by memory pressure is that from child to parent.
Anything else (e.g. an opened file, current directory, mountpoint,
etc.) is out of limits - it either won't be going away until
the thing is not pinned anymore (close, chdir, etc.) *or*
it really shouldn't be ("VM wants this mountpoint dentry freed,
so just dissolve the mount" is a bloody bad idea for obvious
reasons).
Stuff in somebody's shrink list is none of our business - somebody
else is going to try and evict it anyway; if it can be evicted,
it will be.
Anything with zero refcount that isn't in somebody else's
shrink list is fair game.
Directories with children could, in principle, be helped along -
we could try shrink_dcache_parent() on them, which might end
up leaving them with zero refcount. However, it's not cheap
and if you pick the root dentry of a filesystem, it'll try to
evict everything on it that can be evicted, be it in this page
or not. And there's no promise that it will end up evictable
after that.
So from the correctness POV
* you can kick out everything with zero refcount not
on shrink lists.
* you _might_ try shrink_dcache_parent() on directory
dentries, in hope to drive their refcount to zero. However,
that's almost certainly going to hit too hard and be too costly.
* d_invalidate() is no-go; if anything, you want something
weaker than shrink_dcache_parent(), not stronger.
For anything beyond "just kick out everything in that page that
happens to have zero refcount" I would really like to see the
stats - how much does it help, how costly it is _and_ how much
of the cache does it throw away (see above re running into a root
dentry of some filesystem and essentially trimming dcache for
that fs down to the unevictable stuff).
next prev parent reply other threads:[~2019-04-03 19:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-03 4:21 [RFC PATCH v2 00/14] Slab Movable Objects (SMO) Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 01/14] slub: Add isolate() and migrate() methods Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 02/14] tools/vm/slabinfo: Add support for -C and -M options Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 03/14] slub: Sort slab cache list Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 04/14] slub: Slab defrag core Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 05/14] tools/vm/slabinfo: Add remote node defrag ratio output Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 06/14] tools/vm/slabinfo: Add defrag_used_ratio output Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 07/14] tools/testing/slab: Add object migration test module Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 08/14] tools/testing/slab: Add object migration test suite Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 09/14] xarray: Implement migration function for objects Tobin C. Harding
2019-04-03 17:23 ` Matthew Wilcox
2019-04-03 21:19 ` Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 10/14] tools/testing/slab: Add XArray movable objects tests Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 11/14] slub: Enable moving objects to/from specific nodes Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 12/14] slub: Enable balancing slabs across nodes Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 13/14] dcache: Provide a dentry constructor Tobin C. Harding
2019-04-03 4:21 ` [RFC PATCH v2 14/14] dcache: Implement object migration Tobin C. Harding
2019-04-03 17:08 ` Al Viro
2019-04-03 17:19 ` Al Viro
2019-04-03 17:48 ` Al Viro
2019-04-04 20:29 ` Tobin C. Harding
2019-04-04 21:58 ` Al Viro
2019-04-04 21:18 ` Tobin C. Harding
2019-04-03 17:56 ` Christopher Lameter
2019-04-03 18:24 ` Al Viro
2019-04-03 19:05 ` Al Viro [this message]
2019-04-04 8:01 ` Miklos Szeredi
2019-04-04 15:46 ` Christopher Lameter
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=20190403190520.GW2217@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=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).