[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F0DCAA7.4000601@linux.vnet.ibm.com>
Date: Wed, 11 Jan 2012 11:45:11 -0600
From: Seth Jennings <sjenning@...ux.vnet.ibm.com>
To: Dan Magenheimer <dan.magenheimer@...cle.com>
CC: Greg Kroah-Hartman <gregkh@...e.de>,
Nitin Gupta <ngupta@...are.org>,
Brian King <brking@...ux.vnet.ibm.com>,
Konrad Wilk <konrad.wilk@...cle.com>,
Dave Hansen <dave@...ux.vnet.ibm.com>, linux-mm@...ck.org,
devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] staging: zsmalloc: zsmalloc memory allocation library
On 01/11/2012 11:19 AM, Dan Magenheimer wrote:
>> From: Seth Jennings [mailto:sjenning@...ux.vnet.ibm.com]
>> Subject: [PATCH 1/5] staging: zsmalloc: zsmalloc memory allocation library
>>
>> From: Nitin Gupta <ngupta@...are.org>
>>
>> This patch creates a new memory allocation library named
>> zsmalloc.
>>
>> +/*
>> + * Allocate a zspage for the given size class
>> + */
>> +static struct page *alloc_zspage(struct size_class *class, gfp_t flags)
>> +{
>> + int i, error;
>> + struct page *first_page = NULL;
>> +
>> + /*
>> + * Allocate individual pages and link them together as:
>> + * 1. first page->private = first sub-page
>> + * 2. all sub-pages are linked together using page->lru
>> + * 3. each sub-page is linked to the first page using page->first_page
>> + *
>> + * For each size class, First/Head pages are linked together using
>> + * page->lru. Also, we set PG_private to identify the first page
>> + * (i.e. no other sub-page has this flag set) and PG_private_2 to
>> + * identify the last page.
>> + */
>> + error = -ENOMEM;
>> + for (i = 0; i < class->zspage_order; i++) {
>> + struct page *page, *prev_page;
>> +
>> + page = alloc_page(flags);
>
> Hmmm... I thought we agreed offlist that the new allocator API would
> provide for either preloads or callbacks (which may differ per pool)
> instead of directly allocating raw pages from the kernel. The caller
> (zcache or ramster or ???) needs to be able to somehow manage maximum
> memory capacity to avoid OOMs.
>
> Or am I missing the code that handles that?
No, you aren't missing it; it's not there. And I agree that we
should add that.
However, the existing allocator, xvmalloc, doesn't support callback
functionality either. Would it be simpler to add the that as
a separate patch, that way we can keep the changes to zcache/zram
in this patchset isolated to just changing the xvmalloc calls to
zsmalloc calls?
--
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists