From: Roman Gushchin <firstname.lastname@example.org>
To: "Tobin C. Harding" <email@example.com>
Cc: "Tobin C. Harding" <firstname.lastname@example.org>,
Andrew Morton <email@example.com>,
Matthew Wilcox <firstname.lastname@example.org>,
"Alexander Viro" <email@example.com>,
Christoph Hellwig <firstname.lastname@example.org>,
"Pekka Enberg" <email@example.com>,
David Rientjes <firstname.lastname@example.org>,
Joonsoo Kim <email@example.com>,
Christopher Lameter <firstname.lastname@example.org>,
Miklos Szeredi <email@example.com>,
Andreas Dilger <firstname.lastname@example.org>,
Waiman Long <email@example.com>, Tycho Andersen <firstname.lastname@example.org>,
"Theodore Ts'o" <email@example.com>, Andi Kleen <firstname.lastname@example.org>,
David Chinner <email@example.com>,
Nick Piggin <firstname.lastname@example.org>, Rik van Riel <email@example.com>,
Hugh Dickins <firstname.lastname@example.org>, Jonathan Corbet <email@example.com>,
Subject: Re: [RFC PATCH v5 16/16] dcache: Add CONFIG_DCACHE_SMO
Date: Wed, 29 May 2019 16:16:51 +0000 [thread overview]
Message-ID: <20190529161644.GA3228@tower.DHCP.thefacebook.com> (raw)
On Wed, May 29, 2019 at 01:54:06PM +1000, Tobin C. Harding wrote:
> On Tue, May 21, 2019 at 02:05:38AM +0000, Roman Gushchin wrote:
> > On Tue, May 21, 2019 at 11:31:18AM +1000, Tobin C. Harding wrote:
> > > On Tue, May 21, 2019 at 12:57:47AM +0000, Roman Gushchin wrote:
> > > > On Mon, May 20, 2019 at 03:40:17PM +1000, Tobin C. Harding wrote:
> > > > > In an attempt to make the SMO patchset as non-invasive as possible add a
> > > > > config option CONFIG_DCACHE_SMO (under "Memory Management options") for
> > > > > enabling SMO for the DCACHE. Whithout this option dcache constructor is
> > > > > used but no other code is built in, with this option enabled slab
> > > > > mobility is enabled and the isolate/migrate functions are built in.
> > > > >
> > > > > Add CONFIG_DCACHE_SMO to guard the partial shrinking of the dcache via
> > > > > Slab Movable Objects infrastructure.
> > > >
> > > > Hm, isn't it better to make it a static branch? Or basically anything
> > > > that allows switching on the fly?
> > >
> > > If that is wanted, turning SMO on and off per cache, we can probably do
> > > this in the SMO code in SLUB.
> > Not necessarily per cache, but without recompiling the kernel.
> > >
> > > > It seems that the cost of just building it in shouldn't be that high.
> > > > And the question if the defragmentation worth the trouble is so much
> > > > easier to answer if it's possible to turn it on and off without rebooting.
> > >
> > > If the question is 'is defragmentation worth the trouble for the
> > > dcache', I'm not sure having SMO turned off helps answer that question.
> > > If one doesn't shrink the dentry cache there should be very little
> > > overhead in having SMO enabled. So if one wants to explore this
> > > question then they can turn on the config option. Please correct me if
> > > I'm wrong.
> > The problem with a config option is that it's hard to switch over.
> > So just to test your changes in production a new kernel should be built,
> > tested and rolled out to a representative set of machines (which can be
> > measured in thousands of machines). Then if results are questionable,
> > it should be rolled back.
> > What you're actually guarding is the kmem_cache_setup_mobility() call,
> > which can be perfectly avoided using a boot option, for example. Turning
> > it on and off completely dynamic isn't that hard too.
> Hi Roman,
> I've added a boot parameter to SLUB so that admins can enable/disable
> SMO at boot time system wide. Then for each object that implements SMO
> (currently XArray and dcache) I've also added a boot parameter to
> enable/disable SMO for that cache specifically (these depend on SMO
> being enabled system wide).
> All three boot parameters default to 'off', I've added a config option
> to default each to 'on'.
> I've got a little more testing to do on another part of the set then the
> PATCH version is coming at you :)
> This is more a courtesy email than a request for comment, but please
> feel free to shout if you don't like the method outlined above.
> Fully dynamic config is not currently possible because currently the SMO
> implementation does not support disabling mobility for a cache once it
> is turned on, a bit of extra logic would need to be added and some state
> stored - I'm not sure it warrants it ATM but that can be easily added
> later if wanted. Maybe Christoph will give his opinion on this.
next prev parent reply other threads:[~2019-05-29 16:18 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 5:40 [RFC PATCH v5 00/16] Slab Movable Objects (SMO) Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 01/16] slub: Add isolate() and migrate() methods Tobin C. Harding
2019-05-21 0:37 ` Roman Gushchin
2019-05-20 5:40 ` [RFC PATCH v5 02/16] tools/vm/slabinfo: Add support for -C and -M options Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 03/16] slub: Sort slab cache list Tobin C. Harding
2019-05-21 0:38 ` Roman Gushchin
2019-05-20 5:40 ` [RFC PATCH v5 04/16] slub: Slab defrag core Tobin C. Harding
2019-05-21 0:51 ` Roman Gushchin
2019-05-21 1:15 ` Tobin C. Harding
2019-05-21 1:25 ` Roman Gushchin
2019-05-20 5:40 ` [RFC PATCH v5 05/16] tools/vm/slabinfo: Add remote node defrag ratio output Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 06/16] tools/vm/slabinfo: Add defrag_used_ratio output Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 07/16] tools/testing/slab: Add object migration test module Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 08/16] tools/testing/slab: Add object migration test suite Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 09/16] lib: Separate radix_tree_node and xa_node slab cache Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 10/16] xarray: Implement migration function for xa_node objects Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 11/16] tools/testing/slab: Add XArray movable objects tests Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 12/16] slub: Enable moving objects to/from specific nodes Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 13/16] slub: Enable balancing slabs across nodes Tobin C. Harding
2019-05-21 1:04 ` Roman Gushchin
2019-05-21 1:44 ` Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 14/16] dcache: Provide a dentry constructor Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 15/16] dcache: Implement partial shrink via Slab Movable Objects Tobin C. Harding
2019-05-20 5:40 ` [RFC PATCH v5 16/16] dcache: Add CONFIG_DCACHE_SMO Tobin C. Harding
2019-05-21 0:57 ` Roman Gushchin
2019-05-21 1:31 ` Tobin C. Harding
2019-05-21 2:05 ` Roman Gushchin
2019-05-21 3:15 ` Tobin C. Harding
2019-05-29 3:54 ` Tobin C. Harding
2019-05-29 16:16 ` Roman Gushchin [this message]
2019-06-03 4:26 ` Tobin C. Harding
2019-06-03 20:34 ` Roman Gushchin
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).