From: Roman Gushchin <guro@fb.com>
To: "Tobin C. Harding" <tobin@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christopher Lameter <cl@linux.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Matthew Wilcox <willy@infradead.org>,
Tycho Andersen <tycho@tycho.ws>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 04/15] slub: Enable Slab Movable Objects (SMO)
Date: Mon, 11 Mar 2019 22:48:45 +0000 [thread overview]
Message-ID: <20190311224842.GC7915@tower.DHCP.thefacebook.com> (raw)
In-Reply-To: <20190308041426.16654-5-tobin@kernel.org>
On Fri, Mar 08, 2019 at 03:14:15PM +1100, Tobin C. Harding wrote:
> We have now in place a mechanism for adding callbacks to a cache in
> order to be able to implement object migration.
>
> Add a function __move() that implements SMO by moving all objects in a
> slab page using the isolate/migrate callback methods.
>
> Co-developed-by: Christoph Lameter <cl@linux.com>
> Signed-off-by: Tobin C. Harding <tobin@kernel.org>
> ---
> mm/slub.c | 85 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 0133168d1089..6ce866b420f1 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4325,6 +4325,91 @@ int __kmem_cache_create(struct kmem_cache *s, slab_flags_t flags)
> return err;
> }
>
> +/*
> + * Allocate a slab scratch space that is sufficient to keep pointers to
> + * individual objects for all objects in cache and also a bitmap for the
> + * objects (used to mark which objects are active).
> + */
> +static inline void *alloc_scratch(struct kmem_cache *s)
> +{
> + unsigned int size = oo_objects(s->max);
> +
> + return kmalloc(size * sizeof(void *) +
> + BITS_TO_LONGS(size) * sizeof(unsigned long),
> + GFP_KERNEL);
I wonder how big this allocation can be?
Given that the reason for migration is probably highly fragmented memory,
we probably don't want to have a high-order allocation here. So maybe
kvmalloc()?
> +}
> +
> +/*
> + * __move() - Move all objects in the given slab.
> + * @page: The slab we are working on.
> + * @scratch: Pointer to scratch space.
> + * @node: The target node to move objects to.
> + *
> + * If the target node is not the current node then the object is moved
> + * to the target node. If the target node is the current node then this
> + * is an effective way of defragmentation since the current slab page
> + * with its object is exempt from allocation.
> + */
> +static void __move(struct page *page, void *scratch, int node)
> +{
__move() isn't a very explanatory name. kmem_cache_move() (as in Christopher's
version) is much better, IMO. Or maybe move_slab_objects()?
Also, it's usually better to avoid adding new functions without calling them.
Maybe it's possible to merge this patch with (9)?
Thanks!
> + unsigned long objects;
> + struct kmem_cache *s;
> + unsigned long flags;
> + unsigned long *map;
> + void *private;
> + int count;
> + void *p;
> + void **vector = scratch;
> + void *addr = page_address(page);
> +
> + local_irq_save(flags);
> + slab_lock(page);
> +
> + BUG_ON(!PageSlab(page)); /* Must be s slab page */
> + BUG_ON(!page->frozen); /* Slab must have been frozen earlier */
> +
> + s = page->slab_cache;
> + objects = page->objects;
> + map = scratch + objects * sizeof(void **);
> +
> + /* Determine used objects */
> + bitmap_fill(map, objects);
> + for (p = page->freelist; p; p = get_freepointer(s, p))
> + __clear_bit(slab_index(p, s, addr), map);
> +
> + /* Build vector of pointers to objects */
> + count = 0;
> + memset(vector, 0, objects * sizeof(void **));
> + for_each_object(p, s, addr, objects)
> + if (test_bit(slab_index(p, s, addr), map))
> + vector[count++] = p;
> +
> + if (s->isolate)
> + private = s->isolate(s, vector, count);
> + else
> + /* Objects do not need to be isolated */
> + private = NULL;
> +
> + /*
> + * Pinned the objects. Now we can drop the slab lock. The slab
> + * is frozen so it cannot vanish from under us nor will
> + * allocations be performed on the slab. However, unlocking the
> + * slab will allow concurrent slab_frees to proceed. So the
> + * subsystem must have a way to tell from the content of the
> + * object that it was freed.
> + *
> + * If neither RCU nor ctor is being used then the object may be
> + * modified by the allocator after being freed which may disrupt
> + * the ability of the migrate function to tell if the object is
> + * free or not.
> + */
> + slab_unlock(page);
> + local_irq_restore(flags);
> +
> + /* Perform callback to move the objects */
> + s->migrate(s, vector, count, node, private);
> +}
> +
> void kmem_cache_setup_mobility(struct kmem_cache *s,
> kmem_cache_isolate_func isolate,
> kmem_cache_migrate_func migrate)
> --
> 2.21.0
>
next prev parent reply other threads:[~2019-03-11 22:49 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 4:14 [RFC 00/15] mm: Implement " Tobin C. Harding
2019-03-08 4:14 ` [RFC 01/15] slub: Create sysfs field /sys/slab/<cache>/ops Tobin C. Harding
2019-03-11 21:23 ` Roman Gushchin
2019-03-12 1:16 ` Tobin C. Harding
2019-03-08 4:14 ` [RFC 02/15] slub: Add isolate() and migrate() methods Tobin C. Harding
2019-03-08 15:28 ` Tycho Andersen
2019-03-08 16:15 ` Christopher Lameter
2019-03-08 16:22 ` Tycho Andersen
2019-03-08 19:53 ` Tobin C. Harding
2019-03-08 20:08 ` Tycho Andersen
2019-03-11 21:51 ` Roman Gushchin
2019-03-12 1:08 ` Tobin C. Harding
2019-03-12 4:35 ` Christopher Lameter
2019-03-12 18:47 ` Roman Gushchin
2019-03-08 4:14 ` [RFC 03/15] tools/vm/slabinfo: Add support for -C and -F options Tobin C. Harding
2019-03-11 21:54 ` Roman Gushchin
2019-03-12 1:20 ` Tobin C. Harding
2019-03-08 4:14 ` [RFC 04/15] slub: Enable Slab Movable Objects (SMO) Tobin C. Harding
2019-03-11 22:48 ` Roman Gushchin [this message]
2019-03-12 1:47 ` Tobin C. Harding
2019-03-12 18:00 ` Roman Gushchin
2019-03-12 4:39 ` Christopher Lameter
2019-03-08 4:14 ` [RFC 05/15] slub: Sort slab cache list Tobin C. Harding
2019-03-08 4:14 ` [RFC 06/15] tools/vm/slabinfo: Add remote node defrag ratio output Tobin C. Harding
2019-03-08 4:14 ` [RFC 07/15] slub: Add defrag_used_ratio field and sysfs support Tobin C. Harding
2019-03-08 16:01 ` Tycho Andersen
2019-03-11 6:04 ` Tobin C. Harding
2019-03-08 4:14 ` [RFC 08/15] tools/vm/slabinfo: Add defrag_used_ratio output Tobin C. Harding
2019-03-08 4:14 ` [RFC 09/15] slub: Enable slab defragmentation using SMO Tobin C. Harding
2019-03-11 23:35 ` Roman Gushchin
2019-03-12 1:49 ` Tobin C. Harding
2019-03-08 4:14 ` [RFC 10/15] tools/testing/slab: Add object migration test module Tobin C. Harding
2019-03-08 4:14 ` [RFC 11/15] tools/testing/slab: Add object migration test suite Tobin C. Harding
2019-03-08 4:14 ` [RFC 12/15] xarray: Implement migration function for objects Tobin C. Harding
2019-03-12 0:16 ` Roman Gushchin
2019-03-12 1:54 ` Tobin C. Harding
2019-03-08 4:14 ` [RFC 13/15] tools/testing/slab: Add XArray movable objects tests Tobin C. Harding
2019-03-08 4:14 ` [RFC 14/15] slub: Enable move _all_ objects to node Tobin C. Harding
2019-03-08 4:14 ` [RFC 15/15] slub: Enable balancing slab objects across nodes Tobin C. Harding
2019-03-12 0:09 ` [RFC 00/15] mm: Implement Slab Movable Objects (SMO) Roman Gushchin
2019-03-12 1:48 ` 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=20190311224842.GC7915@tower.DHCP.thefacebook.com \
--to=guro@fb.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@cs.helsinki.fi \
--cc=tobin@kernel.org \
--cc=tycho@tycho.ws \
--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