From: "Tobin C. Harding" <email@example.com>
To: Roman Gushchin <firstname.lastname@example.org>
Cc: "Tobin C. Harding" <email@example.com>,
Andrew Morton <firstname.lastname@example.org>,
Matthew Wilcox <email@example.com>,
Alexander Viro <firstname.lastname@example.org>,
Christoph Hellwig <email@example.com>,
Pekka Enberg <firstname.lastname@example.org>,
David Rientjes <email@example.com>,
Joonsoo Kim <firstname.lastname@example.org>,
Christopher Lameter <email@example.com>,
Miklos Szeredi <firstname.lastname@example.org>,
Andreas Dilger <email@example.com>,
Waiman Long <firstname.lastname@example.org>, Tycho Andersen <email@example.com>,
Theodore Ts'o <firstname.lastname@example.org>, Andi Kleen <email@example.com>,
David Chinner <firstname.lastname@example.org>,
Nick Piggin <email@example.com>, Rik van Riel <firstname.lastname@example.org>,
Hugh Dickins <email@example.com>, Jonathan Corbet <firstname.lastname@example.org>,
Subject: Re: [RFC PATCH v5 16/16] dcache: Add CONFIG_DCACHE_SMO
Date: Wed, 29 May 2019 13:54:06 +1000 [thread overview]
Message-ID: <20190529035406.GA23181@eros.localdomain> (raw)
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.
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 3:54 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 [this message]
2019-05-29 16:16 ` Roman Gushchin
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).