> From: Seth Jennings [mailto:sjenning@xxxxxxxxxxxxxxxxxx] > 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@xxxxxxxxxxxxxxxxxx] > >> Subject: [PATCH 1/5] staging: zsmalloc: zsmalloc memory allocation library > >> > >> From: Nitin Gupta <ngupta@xxxxxxxxxx> > >> > >> 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? OK, I'll buy that. Since you haven't changed any of the policy code, and the allocator is (purportedly) more storage-efficient on any sequence of chunks stored in it, the potential for OOMs shouldn't get any worse. Dan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
