linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] slab+slob: dup name string
@ 2012-05-21 15:18 Glauber Costa
  2012-05-21 15:35 ` Christoph Lameter
  2012-05-22  3:22 ` David Rientjes
  0 siblings, 2 replies; 20+ messages in thread
From: Glauber Costa @ 2012-05-21 15:18 UTC (permalink / raw)
  To: linux-kernel
  Cc: cgroups, linux-mm, Glauber Costa, Christoph Lameter,
	Pekka Enberg, David Rientjes

The slub allocator creates a copy of the name string, and
frees it later. I would like all caches to behave the same,
whether it is the slab+slob starting to create a copy of it itself,
or the slub ceasing to.

This patch creates copies of the name string for slob and slab,
adopting slub behavior for them all.

For the slab, we can't really do it before the kmalloc caches are
up. We need to rely that caches created before the state was set to
EARLY will never be destroyed.

Signed-off-by: Glauber Costa <glommer@parallels.com>
CC: Christoph Lameter <cl@linux.com>
CC: Pekka Enberg <penberg@cs.helsinki.fi>
CC: David Rientjes <rientjes@google.com>
---
 mm/slab.c |   10 ++++++++--
 mm/slob.c |   12 ++++++++++--
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index e901a36..cabd217 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2118,6 +2118,7 @@ static void __kmem_cache_destroy(struct kmem_cache *cachep)
 			kfree(l3);
 		}
 	}
+	kfree(cachep->name);
 	kmem_cache_free(&cache_cache, cachep);
 }
 
@@ -2526,9 +2527,14 @@ kmem_cache_create (const char *name, size_t size, size_t align,
 		BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
 	}
 	cachep->ctor = ctor;
-	cachep->name = name;
 
-	if (setup_cpu_cache(cachep, gfp)) {
+	/* Can't do strdup while kmalloc is not up */
+	if (g_cpucache_up > EARLY)
+		cachep->name = kstrdup(name, GFP_KERNEL);
+	else
+		cachep->name = name;
+
+	if (!cachep->name || setup_cpu_cache(cachep, gfp)) {
 		__kmem_cache_destroy(cachep);
 		cachep = NULL;
 		goto oops;
diff --git a/mm/slob.c b/mm/slob.c
index 8105be4..8f10d36 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -575,7 +575,12 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size,
 		GFP_KERNEL, ARCH_KMALLOC_MINALIGN, -1);
 
 	if (c) {
-		c->name = name;
+		c->name = kstrdup(name, GFP_KERNEL);
+		if (!c->name) {
+			slob_free(c, sizeof(struct kmem_cache));
+			c = NULL;
+			goto out;
+		}
 		c->size = size;
 		if (flags & SLAB_DESTROY_BY_RCU) {
 			/* leave room for rcu footer at the end of object */
@@ -589,7 +594,9 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size,
 			c->align = ARCH_SLAB_MINALIGN;
 		if (c->align < align)
 			c->align = align;
-	} else if (flags & SLAB_PANIC)
+	}
+out:
+	if (!c && (flags & SLAB_PANIC))
 		panic("Cannot create slab cache %s\n", name);
 
 	kmemleak_alloc(c, sizeof(struct kmem_cache), 1, GFP_KERNEL);
@@ -602,6 +609,7 @@ void kmem_cache_destroy(struct kmem_cache *c)
 	kmemleak_free(c);
 	if (c->flags & SLAB_DESTROY_BY_RCU)
 		rcu_barrier();
+	kfree(c->name);
 	slob_free(c, sizeof(struct kmem_cache));
 }
 EXPORT_SYMBOL(kmem_cache_destroy);
-- 
1.7.7.6


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-21 15:18 [PATCH] slab+slob: dup name string Glauber Costa
@ 2012-05-21 15:35 ` Christoph Lameter
  2012-05-22  3:22 ` David Rientjes
  1 sibling, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2012-05-21 15:35 UTC (permalink / raw)
  To: Glauber Costa
  Cc: linux-kernel, cgroups, linux-mm, Pekka Enberg, David Rientjes


Acked-by: Christoph Lameter <cl@linux.com>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-21 15:18 [PATCH] slab+slob: dup name string Glauber Costa
  2012-05-21 15:35 ` Christoph Lameter
@ 2012-05-22  3:22 ` David Rientjes
  2012-05-22  7:23   ` Glauber Costa
                     ` (2 more replies)
  1 sibling, 3 replies; 20+ messages in thread
From: David Rientjes @ 2012-05-22  3:22 UTC (permalink / raw)
  To: Glauber Costa
  Cc: linux-kernel, cgroups, linux-mm, Christoph Lameter, Pekka Enberg

On Mon, 21 May 2012, Glauber Costa wrote:

> diff --git a/mm/slab.c b/mm/slab.c
> index e901a36..cabd217 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2118,6 +2118,7 @@ static void __kmem_cache_destroy(struct kmem_cache *cachep)
>  			kfree(l3);
>  		}
>  	}
> +	kfree(cachep->name);
>  	kmem_cache_free(&cache_cache, cachep);
>  }
>  
> @@ -2526,9 +2527,14 @@ kmem_cache_create (const char *name, size_t size, size_t align,
>  		BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
>  	}
>  	cachep->ctor = ctor;
> -	cachep->name = name;
>  
> -	if (setup_cpu_cache(cachep, gfp)) {
> +	/* Can't do strdup while kmalloc is not up */
> +	if (g_cpucache_up > EARLY)
> +		cachep->name = kstrdup(name, GFP_KERNEL);
> +	else
> +		cachep->name = name;
> +
> +	if (!cachep->name || setup_cpu_cache(cachep, gfp)) {
>  		__kmem_cache_destroy(cachep);
>  		cachep = NULL;
>  		goto oops;

This doesn't work if you kmem_cache_destroy() a cache that was created 
when g_cpucache_cpu <= EARLY, the kfree() will explode.  That never 
happens for any existing cache created in kmem_cache_init(), but this 
would introduce the first roadblock in doing so.  So you'll need some 
magic to determine whether the cache was allocated statically and suppress 
the kfree() in such a case.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-22  3:22 ` David Rientjes
@ 2012-05-22  7:23   ` Glauber Costa
  2012-05-22  9:45   ` Glauber Costa
  2012-05-22 13:56   ` Christoph Lameter
  2 siblings, 0 replies; 20+ messages in thread
From: Glauber Costa @ 2012-05-22  7:23 UTC (permalink / raw)
  To: David Rientjes
  Cc: linux-kernel, cgroups, linux-mm, Christoph Lameter, Pekka Enberg

On 05/22/2012 07:22 AM, David Rientjes wrote:
> On Mon, 21 May 2012, Glauber Costa wrote:
>
>> diff --git a/mm/slab.c b/mm/slab.c
>> index e901a36..cabd217 100644
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -2118,6 +2118,7 @@ static void __kmem_cache_destroy(struct kmem_cache *cachep)
>>   			kfree(l3);
>>   		}
>>   	}
>> +	kfree(cachep->name);
>>   	kmem_cache_free(&cache_cache, cachep);
>>   }
>>
>> @@ -2526,9 +2527,14 @@ kmem_cache_create (const char *name, size_t size, size_t align,
>>   		BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
>>   	}
>>   	cachep->ctor = ctor;
>> -	cachep->name = name;
>>
>> -	if (setup_cpu_cache(cachep, gfp)) {
>> +	/* Can't do strdup while kmalloc is not up */
>> +	if (g_cpucache_up>  EARLY)
>> +		cachep->name = kstrdup(name, GFP_KERNEL);
>> +	else
>> +		cachep->name = name;
>> +
>> +	if (!cachep->name || setup_cpu_cache(cachep, gfp)) {
>>   		__kmem_cache_destroy(cachep);
>>   		cachep = NULL;
>>   		goto oops;
>
> This doesn't work if you kmem_cache_destroy() a cache that was created
> when g_cpucache_cpu<= EARLY, the kfree() will explode.  That never
> happens for any existing cache created in kmem_cache_init(), but this
> would introduce the first roadblock in doing so.  So you'll need some
> magic to determine whether the cache was allocated statically and suppress
> the kfree() in such a case.

Suggestions on how to do it other than using a flag?


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-22  3:22 ` David Rientjes
  2012-05-22  7:23   ` Glauber Costa
@ 2012-05-22  9:45   ` Glauber Costa
  2012-05-22 13:56   ` Christoph Lameter
  2 siblings, 0 replies; 20+ messages in thread
From: Glauber Costa @ 2012-05-22  9:45 UTC (permalink / raw)
  To: David Rientjes
  Cc: linux-kernel, cgroups, linux-mm, Christoph Lameter, Pekka Enberg

On 05/22/2012 07:22 AM, David Rientjes wrote:
>> -	if (setup_cpu_cache(cachep, gfp)) {
>> >  +	/* Can't do strdup while kmalloc is not up */
>> >  +	if (g_cpucache_up>  EARLY)
>> >  +		cachep->name = kstrdup(name, GFP_KERNEL);
>> >  +	else
>> >  +		cachep->name = name;
>> >  +
>> >  +	if (!cachep->name || setup_cpu_cache(cachep, gfp)) {
>> >    		__kmem_cache_destroy(cachep);
>> >    		cachep = NULL;
>> >    		goto oops;
> This doesn't work if you kmem_cache_destroy() a cache that was created
> when g_cpucache_cpu<= EARLY, the kfree() will explode.  That never
> happens for any existing cache created in kmem_cache_init(), but this
> would introduce the first roadblock in doing so.  So you'll need some
> magic to determine whether the cache was allocated statically and suppress
> the kfree() in such a case.

David,

I tried to do something like I was doing for the memcg caches: after 
creation of the kmalloc + cache_cache, I loop through them and duplicate 
the name. So instead of conditionally freeing the late caches - that 
could cause consistency headaches in the future - kfree'ing the name 
string will just work for all of them. I will send it shortly.

Cristoph, I am dropping your ack since this change is quite significant. 
If you agree with it, would you ack it again?

Thanks.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-22  3:22 ` David Rientjes
  2012-05-22  7:23   ` Glauber Costa
  2012-05-22  9:45   ` Glauber Costa
@ 2012-05-22 13:56   ` Christoph Lameter
  2012-05-22 15:19     ` Glauber Costa
  2 siblings, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2012-05-22 13:56 UTC (permalink / raw)
  To: David Rientjes
  Cc: Glauber Costa, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Mon, 21 May 2012, David Rientjes wrote:

> This doesn't work if you kmem_cache_destroy() a cache that was created
> when g_cpucache_cpu <= EARLY, the kfree() will explode.  That never
> happens for any existing cache created in kmem_cache_init(), but this
> would introduce the first roadblock in doing so.  So you'll need some
> magic to determine whether the cache was allocated statically and suppress
> the kfree() in such a case.

Nope. Only slab management caches will be created that early. The patch is
fine as is.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-22 13:56   ` Christoph Lameter
@ 2012-05-22 15:19     ` Glauber Costa
  2012-05-22 17:16       ` Christoph Lameter
  0 siblings, 1 reply; 20+ messages in thread
From: Glauber Costa @ 2012-05-22 15:19 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: David Rientjes, linux-kernel, cgroups, linux-mm, Pekka Enberg

On 05/22/2012 05:56 PM, Christoph Lameter wrote:
> On Mon, 21 May 2012, David Rientjes wrote:
>
>> This doesn't work if you kmem_cache_destroy() a cache that was created
>> when g_cpucache_cpu<= EARLY, the kfree() will explode.  That never
>> happens for any existing cache created in kmem_cache_init(), but this
>> would introduce the first roadblock in doing so.  So you'll need some
>> magic to determine whether the cache was allocated statically and suppress
>> the kfree() in such a case.
>
> Nope. Only slab management caches will be created that early. The patch is
> fine as is.
>
>

I think that's precisely David's point: that we might want to destroy 
them eventually.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-22 15:19     ` Glauber Costa
@ 2012-05-22 17:16       ` Christoph Lameter
  2012-05-22 22:31         ` David Rientjes
  0 siblings, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2012-05-22 17:16 UTC (permalink / raw)
  To: Glauber Costa
  Cc: David Rientjes, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Tue, 22 May 2012, Glauber Costa wrote:

> I think that's precisely David's point: that we might want to destroy them
> eventually.

Cannot imagine why.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-22 17:16       ` Christoph Lameter
@ 2012-05-22 22:31         ` David Rientjes
  2012-05-23 11:46           ` James Bottomley
  2012-05-23 13:48           ` Christoph Lameter
  0 siblings, 2 replies; 20+ messages in thread
From: David Rientjes @ 2012-05-22 22:31 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Glauber Costa, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Tue, 22 May 2012, Christoph Lameter wrote:

> > I think that's precisely David's point: that we might want to destroy them
> > eventually.
> 
> Cannot imagine why.
> 

We can't predict how slab will be extended in the future and this affects 
anything created before g_cpucache_cpu <= EARLY.  This would introduce the 
first problem with destroying such caches and is unnecessary if a 
workaround exists.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-22 22:31         ` David Rientjes
@ 2012-05-23 11:46           ` James Bottomley
  2012-05-23 12:08             ` Glauber Costa
  2012-05-23 13:48           ` Christoph Lameter
  1 sibling, 1 reply; 20+ messages in thread
From: James Bottomley @ 2012-05-23 11:46 UTC (permalink / raw)
  To: David Rientjes
  Cc: Christoph Lameter, Glauber Costa, linux-kernel, cgroups,
	linux-mm, Pekka Enberg

On Tue, 2012-05-22 at 15:31 -0700, David Rientjes wrote:
> On Tue, 22 May 2012, Christoph Lameter wrote:
> 
> > > I think that's precisely David's point: that we might want to destroy them
> > > eventually.
> > 
> > Cannot imagine why.
> > 
> 
> We can't predict how slab will be extended in the future and this affects 
> anything created before g_cpucache_cpu <= EARLY.  This would introduce the 
> first problem with destroying such caches and is unnecessary if a 
> workaround exists.

These problems seem to indicate that the slab behaviour: expecting the
string to exist for the lifetime of the cache so there's no need to copy
it might be better.

This must be the behaviour all users of kmem_cache_create() expect
anyway, since all enterprise distributions use slab and they're not
getting bugs reported in this area.

So, why not simply patch slab to rely on the string lifetime being the
cache lifetime (or beyond) and therefore not having it take a copy?

James



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-23 11:46           ` James Bottomley
@ 2012-05-23 12:08             ` Glauber Costa
  2012-05-23 12:24               ` James Bottomley
  0 siblings, 1 reply; 20+ messages in thread
From: Glauber Costa @ 2012-05-23 12:08 UTC (permalink / raw)
  To: James Bottomley
  Cc: David Rientjes, Christoph Lameter, linux-kernel, cgroups,
	linux-mm, Pekka Enberg

On 05/23/2012 03:46 PM, James Bottomley wrote:
>> We can't predict how slab will be extended in the future and this affects
>> >  anything created before g_cpucache_cpu<= EARLY.  This would introduce the
>> >  first problem with destroying such caches and is unnecessary if a
>> >  workaround exists.
> These problems seem to indicate that the slab behaviour: expecting the
> string to exist for the lifetime of the cache so there's no need to copy
> it might be better.
>
> This must be the behaviour all users of kmem_cache_create() expect
> anyway, since all enterprise distributions use slab and they're not
> getting bugs reported in this area.
>
> So, why not simply patch slab to rely on the string lifetime being the
> cache lifetime (or beyond) and therefore not having it take a copy?
>
You mean patch slub? slub is the one that takes a copy currently.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-23 12:08             ` Glauber Costa
@ 2012-05-23 12:24               ` James Bottomley
  2012-05-23 14:48                 ` Christoph Lameter
  0 siblings, 1 reply; 20+ messages in thread
From: James Bottomley @ 2012-05-23 12:24 UTC (permalink / raw)
  To: Glauber Costa
  Cc: David Rientjes, Christoph Lameter, linux-kernel, cgroups,
	linux-mm, Pekka Enberg

On Wed, 2012-05-23 at 16:08 +0400, Glauber Costa wrote:
> On 05/23/2012 03:46 PM, James Bottomley wrote:
> >> We can't predict how slab will be extended in the future and this affects
> >> >  anything created before g_cpucache_cpu<= EARLY.  This would introduce the
> >> >  first problem with destroying such caches and is unnecessary if a
> >> >  workaround exists.
> > These problems seem to indicate that the slab behaviour: expecting the
> > string to exist for the lifetime of the cache so there's no need to copy
> > it might be better.
> >
> > This must be the behaviour all users of kmem_cache_create() expect
> > anyway, since all enterprise distributions use slab and they're not
> > getting bugs reported in this area.
> >
> > So, why not simply patch slab to rely on the string lifetime being the
> > cache lifetime (or beyond) and therefore not having it take a copy?
> >
> You mean patch slub? slub is the one that takes a copy currently.

Yes ... a one letter typo.  

James



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-22 22:31         ` David Rientjes
  2012-05-23 11:46           ` James Bottomley
@ 2012-05-23 13:48           ` Christoph Lameter
  1 sibling, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2012-05-23 13:48 UTC (permalink / raw)
  To: David Rientjes
  Cc: Glauber Costa, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Tue, 22 May 2012, David Rientjes wrote:

> On Tue, 22 May 2012, Christoph Lameter wrote:
>
> > > I think that's precisely David's point: that we might want to destroy them
> > > eventually.
> >
> > Cannot imagine why.
> >
>
> We can't predict how slab will be extended in the future and this affects
> anything created before g_cpucache_cpu <= EARLY.  This would introduce the
> first problem with destroying such caches and is unnecessary if a
> workaround exists.

Changes to the very early bootstrap code of slab allocators are rare and
the code there is dicey anyways. It is much more risky to add additional
allocations of varying length at that stage.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-23 12:24               ` James Bottomley
@ 2012-05-23 14:48                 ` Christoph Lameter
  2012-05-23 14:50                   ` Glauber Costa
  2012-05-23 15:01                   ` Glauber Costa
  0 siblings, 2 replies; 20+ messages in thread
From: Christoph Lameter @ 2012-05-23 14:48 UTC (permalink / raw)
  To: James Bottomley
  Cc: Glauber Costa, David Rientjes, linux-kernel, cgroups, linux-mm,
	Pekka Enberg

On Wed, 23 May 2012, James Bottomley wrote:

> > > So, why not simply patch slab to rely on the string lifetime being the
> > > cache lifetime (or beyond) and therefore not having it take a copy?

Well thats they way it was for a long time. There must be some reason that
someone started to add this copying business....  Pekka?


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-23 14:48                 ` Christoph Lameter
@ 2012-05-23 14:50                   ` Glauber Costa
  2012-05-24  0:18                     ` Dave Chinner
  2012-05-23 15:01                   ` Glauber Costa
  1 sibling, 1 reply; 20+ messages in thread
From: Glauber Costa @ 2012-05-23 14:50 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: James Bottomley, David Rientjes, linux-kernel, cgroups, linux-mm,
	Pekka Enberg

On 05/23/2012 06:48 PM, Christoph Lameter wrote:
> On Wed, 23 May 2012, James Bottomley wrote:
>
>>>> So, why not simply patch slab to rely on the string lifetime being the
>>>> cache lifetime (or beyond) and therefore not having it take a copy?
>
> Well thats they way it was for a long time. There must be some reason that
> someone started to add this copying business....  Pekka?
>
The question is less why we added, but rather why we're keeping.

Of course reasoning about why it was added helps (so let's try to 
determine that), but so far the only reasonably strong argument in favor 
of keeping it was robustness.

But given that a lot of systems still uses SLAB, and we have no record 
of bugs due to dangling name pointers, this might very well be 
overzealousness on our part.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-23 14:48                 ` Christoph Lameter
  2012-05-23 14:50                   ` Glauber Costa
@ 2012-05-23 15:01                   ` Glauber Costa
  2012-05-23 15:17                     ` Christoph Lameter
  1 sibling, 1 reply; 20+ messages in thread
From: Glauber Costa @ 2012-05-23 15:01 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: James Bottomley, David Rientjes, linux-kernel, cgroups, linux-mm,
	Pekka Enberg

On 05/23/2012 06:48 PM, Christoph Lameter wrote:
> On Wed, 23 May 2012, James Bottomley wrote:
>
>>>> So, why not simply patch slab to rely on the string lifetime being the
>>>> cache lifetime (or beyond) and therefore not having it take a copy?
>
> Well thats they way it was for a long time. There must be some reason that
> someone started to add this copying business....  Pekka?
>

 From git:

commit 84c1cf62465e2fb0a692620dcfeb52323ab03d48
Author: Pekka Enberg <penberg@kernel.org>
Date:   Tue Sep 14 23:21:12 2010 +0300

SLUB: Fix merged slab cache names

As explained by Linus "I'm Proud to be an American" Torvalds:

Looking at the merging code, I actually think it's totally
buggy. If you have something like this:

  - load module A: create slab cache A

  - load module B: create slab cache B that can merge with A

  - unload module A

  - "cat /proc/slabinfo": BOOM. Oops.

exactly because the name is not handled correctly, and you'll have
module B holding open a slab cache that has a name pointer that points
to module A that no longer exists.

So if I understand it correctly, this is mostly because the name string 
outlives the cache in the slub case, because of merging ?

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-23 15:17                     ` Christoph Lameter
@ 2012-05-23 15:15                       ` Glauber Costa
  0 siblings, 0 replies; 20+ messages in thread
From: Glauber Costa @ 2012-05-23 15:15 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: James Bottomley, David Rientjes, linux-kernel, cgroups, linux-mm,
	Pekka Enberg

On 05/23/2012 07:17 PM, Christoph Lameter wrote:
>> So if I understand it correctly, this is mostly because the name string
>> >  outlives the cache in the slub case, because of merging ?
> Well this means we really only need the copying in slub which we already
> have.
>
> The problem is that you want to make this behavior uniform over all
> allocators so that you do not have to allocate the string on your own.
>
> Could you wait (and not rely on copying) until I am through with the
> extraction project for common code for the allocators? At that point we
> can resolve this issue consistently for all allocators.
>

Yes, I can.
Let's just defer this for now.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-23 15:01                   ` Glauber Costa
@ 2012-05-23 15:17                     ` Christoph Lameter
  2012-05-23 15:15                       ` Glauber Costa
  0 siblings, 1 reply; 20+ messages in thread
From: Christoph Lameter @ 2012-05-23 15:17 UTC (permalink / raw)
  To: Glauber Costa
  Cc: James Bottomley, David Rientjes, linux-kernel, cgroups, linux-mm,
	Pekka Enberg

On Wed, 23 May 2012, Glauber Costa wrote:

> So if I understand it correctly, this is mostly because the name string
> outlives the cache in the slub case, because of merging ?

Well this means we really only need the copying in slub which we already
have.

The problem is that you want to make this behavior uniform over all
allocators so that you do not have to allocate the string on your own.

Could you wait (and not rely on copying) until I am through with the
extraction project for common code for the allocators? At that point we
can resolve this issue consistently for all allocators.




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-23 14:50                   ` Glauber Costa
@ 2012-05-24  0:18                     ` Dave Chinner
  2012-05-24 12:06                       ` Glauber Costa
  0 siblings, 1 reply; 20+ messages in thread
From: Dave Chinner @ 2012-05-24  0:18 UTC (permalink / raw)
  To: Glauber Costa
  Cc: Christoph Lameter, James Bottomley, David Rientjes, linux-kernel,
	cgroups, linux-mm, Pekka Enberg

On Wed, May 23, 2012 at 06:50:57PM +0400, Glauber Costa wrote:
> On 05/23/2012 06:48 PM, Christoph Lameter wrote:
> >On Wed, 23 May 2012, James Bottomley wrote:
> >
> >>>>So, why not simply patch slab to rely on the string lifetime being the
> >>>>cache lifetime (or beyond) and therefore not having it take a copy?
> >
> >Well thats they way it was for a long time. There must be some reason that
> >someone started to add this copying business....  Pekka?
> >
> The question is less why we added, but rather why we're keeping.
> 
> Of course reasoning about why it was added helps (so let's try to
> determine that), but so far the only reasonably strong argument in
> favor of keeping it was robustness.

I'm pretty sure it was added because there are slab names
constructed by snprintf on a stack buffer, so the name doesn't exist
beyond the slab initialisation function call...

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH] slab+slob: dup name string
  2012-05-24  0:18                     ` Dave Chinner
@ 2012-05-24 12:06                       ` Glauber Costa
  0 siblings, 0 replies; 20+ messages in thread
From: Glauber Costa @ 2012-05-24 12:06 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Christoph Lameter, James Bottomley, David Rientjes, linux-kernel,
	cgroups, linux-mm, Pekka Enberg

On 05/24/2012 04:18 AM, Dave Chinner wrote:
>> Of course reasoning about why it was added helps (so let's try to
>> >  determine that), but so far the only reasonably strong argument in
>> >  favor of keeping it was robustness.
> I'm pretty sure it was added because there are slab names
> constructed by snprintf on a stack buffer, so the name doesn't exist
> beyond the slab initialisation function call...
>
> Cheers,
>
> Dave.
If that was the reason, we'd be seeing slab failing miserably where slub 
succeeds, since slab keeps no copy.



^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2012-05-24 12:08 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-21 15:18 [PATCH] slab+slob: dup name string Glauber Costa
2012-05-21 15:35 ` Christoph Lameter
2012-05-22  3:22 ` David Rientjes
2012-05-22  7:23   ` Glauber Costa
2012-05-22  9:45   ` Glauber Costa
2012-05-22 13:56   ` Christoph Lameter
2012-05-22 15:19     ` Glauber Costa
2012-05-22 17:16       ` Christoph Lameter
2012-05-22 22:31         ` David Rientjes
2012-05-23 11:46           ` James Bottomley
2012-05-23 12:08             ` Glauber Costa
2012-05-23 12:24               ` James Bottomley
2012-05-23 14:48                 ` Christoph Lameter
2012-05-23 14:50                   ` Glauber Costa
2012-05-24  0:18                     ` Dave Chinner
2012-05-24 12:06                       ` Glauber Costa
2012-05-23 15:01                   ` Glauber Costa
2012-05-23 15:17                     ` Christoph Lameter
2012-05-23 15:15                       ` Glauber Costa
2012-05-23 13:48           ` Christoph Lameter

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).