On Fri, 2012-07-06 at 14:13 +0400, Glauber Costa wrote:
> On 07/05/2012 01:29 PM, Li Zhong wrote:
> > On Thu, 2012-07-05 at 12:23 +0400, Glauber Costa wrote:
> >> On 07/05/2012 05:41 AM, Li Zhong wrote:
> >>> On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote:
> On 07/04/2012 01:00 PM, Li
On 07/05/2012 01:29 PM, Li Zhong wrote:
> On Thu, 2012-07-05 at 12:23 +0400, Glauber Costa wrote:
>> On 07/05/2012 05:41 AM, Li Zhong wrote:
>>> On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote:
On 07/04/2012 01:00 PM, Li Zhong wrote:
> On Tue, 2012-07-03 at 15:36 -0500, Christoph La
On Thu, 2012-07-05 at 12:23 +0400, Glauber Costa wrote:
> On 07/05/2012 05:41 AM, Li Zhong wrote:
> > On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote:
> >> On 07/04/2012 01:00 PM, Li Zhong wrote:
> >>> On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote:
> > Looking through the em
On 07/05/2012 05:41 AM, Li Zhong wrote:
> On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote:
>> On 07/04/2012 01:00 PM, Li Zhong wrote:
>>> On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote:
> Looking through the emails it seems that there is an issue with alias
> strings.
>>
On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote:
> On 07/04/2012 01:00 PM, Li Zhong wrote:
> > On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote:
> >> > Looking through the emails it seems that there is an issue with alias
> >> > strings.
> > To be more precise, there seems no big
On 07/04/2012 01:00 PM, Li Zhong wrote:
> On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote:
>> > Looking through the emails it seems that there is an issue with alias
>> > strings.
> To be more precise, there seems no big issue currently. I just wanted to
> make following usage of kmem_c
On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote:
> Looking through the emails it seems that there is an issue with alias
> strings.
To be more precise, there seems no big issue currently. I just wanted to
make following usage of kmem_cache_create (SLUB) possible:
name = some s
Looking through the emails it seems that there is an issue with alias
strings. That can be solved by duping the name of the slab earlier in
kmem_cache_create().
Does this patch fix the issue?
Subject: slub: Dup name earlier in kmem_cache_create
Dup the name earlier in kmem_cache_create so that a
On Mon, 25 Jun 2012, Li Zhong wrote:
> This patch tries to kfree the cache name of pgtables cache if SLUB is
> used, as SLUB duplicates the cache name, and the original one is leaked.
SLAB also does not free the name. Why would you have an #ifdef in there?
On 06/29/2012 08:45 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-06-25 at 17:54 +0800, Li Zhong wrote:
>
>> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
>> index 620b7ac..c9d2a7f 100644
>> --- a/arch/powerpc/mm/init_64.c
>> +++ b/arch/powerpc/mm/init_64.c
>> @@ -130,6 +13
On Mon, 2012-06-25 at 17:54 +0800, Li Zhong wrote:
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index 620b7ac..c9d2a7f 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -130,6 +130,9 @@ void pgtable_cache_add(unsigned shift, void
> (*ctor)(vo
This patch tries to kfree the cache name of pgtables cache if SLUB is
used, as SLUB duplicates the cache name, and the original one is leaked.
This patch depends on patch 1 -- (duplicate the cache name in
saved_alias list) in this mail thread. As the pgtables cache might be
merged to other caches.
12 matches
Mail list logo
