Re: [PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB

2012-07-09 Thread Christoph Lameter
I was pointed by Glauber to the slab common code patches. I need some more time to read the patches. Now I think the slab/slot changes in this v3 are not needed, and can be ignored. That may take some kernel cycles. You have a current issue here that needs to be fixed.

Re: [PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB

2012-07-09 Thread Li Zhong
On Mon, 2012-07-09 at 09:01 -0500, Christoph Lameter wrote: I was pointed by Glauber to the slab common code patches. I need some more time to read the patches. Now I think the slab/slot changes in this v3 are not needed, and can be ignored. That may take some kernel cycles. You have a

Re: [PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB

2012-07-08 Thread Li Zhong
On Fri, 2012-07-06 at 08:56 -0500, Christoph Lameter wrote: I thought I posted this a couple of days ago. Would this not fix things without having to change all the allocators? I was pointed by Glauber to the slab common code patches. I need some more time to read the patches. Now I think the

Re: [PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB

2012-07-06 Thread Glauber Costa
On 07/06/2012 11:54 AM, Li Zhong wrote: + if (!c lname) + kfree(lname); + kfree can still be validly called with a NULL argument. No need for the lname in the conditional. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: [PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB

2012-07-06 Thread Christoph Lameter
I thought I posted this a couple of days ago. Would this not fix things without having to change all the allocators? Subject: slub: Dup name earlier in kmem_cache_create Dup the name earlier in kmem_cache_create so that alias processing is done using the copy of the string and not the string