From: Glauber Costa <glommer@parallels.com>
To: Pavel Emelyanov <xemul@parallels.com>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
linux-mm@kvack.org, Cyrill Gorcunov <gorcunov@openvz.org>,
Andrew Morton <akpm@linux-foundation.org>,
devel@openvz.org, Greg Thelen <gthelen@google.com>,
Suleiman Souhlal <suleiman@google.com>
Subject: Re: [PATCH 2/5] slab_id: Generic slab ID infrastructure
Date: Fri, 7 Oct 2011 12:27:46 +0400 [thread overview]
Message-ID: <4E8EB802.8020201@parallels.com> (raw)
In-Reply-To: <4E8DD600.7070700@parallels.com>
Hi Pavel,
On 10/06/2011 08:23 PM, Pavel Emelyanov wrote:
> The idea of how to generate and ID for an arbitrary slab object is simple:
>
> - The ID is 128 bits
> - The upper 64 bits are slab ID
> - The lower 64 bits are object index withing a slab (yes, it's too many,
> but is done for simplicity - not to deal with 96-bit numbers)
> - The slab ID is the 48-bit per-cpu monotonic counter mixed with 16-bit
> cpuid. Even if being incremented 1M times per second the first part
> will stay uniqe for 200+ years. The cpuid is required to make values
> picked on two cpus differ.
So why can't we just use tighter numbers, and leave some reserved fields
instead ?
Having ids in the objects of the slab may prove useful in the future for
other uses as well.
For instance, concurrent to that, we're trying to figure out ways to
have per-cgroup pages/objects accounted in the memory controller.
The most up2date proposals create an entire kmem cache for each cgroup,
thus trivially guaranteeing uniqueness. It however, leads to fragmentation.
Having the objects to be IDed and being cgroup part of this id, could
help us achieve the same goal with less fragmentation.
>
> Signed-off-by: Pavel Emelyanov<xemul@parallels.com>
>
> ---
> include/linux/slab.h | 17 +++++++++++++++++
> init/Kconfig | 9 +++++++++
> mm/Makefile | 1 +
> mm/slab_obj_ids.c | 25 +++++++++++++++++++++++++
> 4 files changed, 52 insertions(+), 0 deletions(-)
> create mode 100644 mm/slab_obj_ids.c
>
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 573c809..ae9c735 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -23,6 +23,7 @@
> #define SLAB_CACHE_DMA 0x00004000UL /* Use GFP_DMA memory */
> #define SLAB_STORE_USER 0x00010000UL /* DEBUG: Store the last owner for bug hunting */
> #define SLAB_PANIC 0x00040000UL /* Panic if kmem_cache_create() fails */
> +#define SLAB_WANT_OBJIDS 0x00080000UL /* Want GENERIC_OBJECT_IDS-friendly slabs */
> /*
> * SLAB_DESTROY_BY_RCU - **WARNING** READ THIS!
> *
> @@ -162,6 +163,22 @@ void kfree(const void *);
> void kzfree(const void *);
> size_t ksize(const void *);
>
> +#ifdef CONFIG_SLAB_OBJECT_IDS
> +void __slab_pick_id(u64 *s_id);
> +static inline void __slab_get_id(u64 *id, u64 s_id, u64 o_id)
> +{
> + id[0] = o_id;
> + id[1] = s_id;
> +}
> +
> +void k_object_id(const void *, u64 *id);
> +#else
> +static inline void k_object_id(const void *x, u64 *id)
> +{
> + id[0] = id[1] = 0;
> +}
> +#endif
> +
> /*
> * Allocator specific definitions. These are mainly used to establish optimized
> * ways to convert kmalloc() calls to kmem_cache_alloc() invocations by
> diff --git a/init/Kconfig b/init/Kconfig
> index d627783..4c1c0e6 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1200,6 +1200,15 @@ config SLUB_DEBUG
> SLUB sysfs support. /sys/slab will not exist and there will be
> no support for cache validation etc.
>
> +config SLAB_OBJECT_IDS
> + default y
> + bool "Enable slab kernel object ID infrastructure"
> + depends on !SLOB
> + help
> + This option provides an infrastructure for calculating ID-s of
> + slab/slub objects. These ID-s are not based on the object location
> + in memory and thus can be shown to the userspace.
> +
> config COMPAT_BRK
> bool "Disable heap randomization"
> default y
> diff --git a/mm/Makefile b/mm/Makefile
> index 836e416..fb65080 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -50,3 +50,4 @@ obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o
> obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
> obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
> obj-$(CONFIG_CLEANCACHE) += cleancache.o
> +obj-$(CONFIG_SLAB_OBJECT_IDS) += slab_obj_ids.o
> diff --git a/mm/slab_obj_ids.c b/mm/slab_obj_ids.c
> new file mode 100644
> index 0000000..87d1693
> --- /dev/null
> +++ b/mm/slab_obj_ids.c
> @@ -0,0 +1,25 @@
> +#include<linux/percpu.h>
> +
> +#define SLUB_ID_CPU_SHIFT 16
> +static DEFINE_PER_CPU(u64, slub_ids);
> +
> +void __slab_pick_id(u64 *s_id)
> +{
> + int cpu;
> + u64 id;
> +
> + /*
> + * The idea behind this all is very simple:
> + *
> + * The ID is the 48-bit per-cpu monotonic counter mixed with 16-bit cpuid.
> + * Even if being incremented 1M times per second the first part will stay
> + * uniqe for 200+ years. The cpuid is required to make values picked on
> + * two cpus differ.
> + */
> +
> + cpu = get_cpu();
> + id = ++per_cpu(slub_ids, cpu);
> + WARN_ON_ONCE(id>> (64 - SLUB_ID_CPU_SHIFT) != 0);
> + *s_id = (id<< SLUB_ID_CPU_SHIFT) | cpu;
> + put_cpu();
> +}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-10-07 8:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-06 16:22 [PATCH 0/5] Slab objects identifiers Pavel Emelyanov
2011-10-06 16:23 ` [PATCH 1/5] slab: Tossing bits around Pavel Emelyanov
2011-10-06 16:23 ` [PATCH 2/5] slab_id: Generic slab ID infrastructure Pavel Emelyanov
2011-10-07 8:27 ` Glauber Costa [this message]
2011-10-07 8:31 ` Pavel Emelyanov
2011-10-06 16:23 ` [PATCH 3/5] slab_id: Slab support for IDs Pavel Emelyanov
2011-10-06 16:24 ` [PATCH 4/5] slab_id: Slub " Pavel Emelyanov
2011-10-06 16:24 ` [PATCH 5/5] slab_id: Show the task's mm ID in proc Pavel Emelyanov
2011-10-07 17:03 ` [PATCH 0/5] Slab objects identifiers Christoph Lameter
2011-10-10 10:20 ` Pavel Emelyanov
2011-10-10 15:24 ` Christoph Lameter
2011-10-10 15:46 ` Pavel Emelyanov
2011-10-13 7:12 ` Pekka Enberg
2011-10-13 11:25 ` Pavel Emelyanov
2011-10-13 12:12 ` Pekka Enberg
2011-10-13 12:23 ` Pavel Emelyanov
2011-10-10 18:59 ` Matt Helsley
2011-10-11 7:50 ` Pavel Emelyanov
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=4E8EB802.8020201@parallels.com \
--to=glommer@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=devel@openvz.org \
--cc=gorcunov@openvz.org \
--cc=gthelen@google.com \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
--cc=suleiman@google.com \
--cc=xemul@parallels.com \
/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).