On 01/11/2012 11:19 AM, Dan Magenheimer wrote: >> From: Seth Jennings [mailto:[email protected]] >> Subject: [PATCH 1/5] staging: zsmalloc: zsmalloc memory allocation library >> >> From: Nitin Gupta <[email protected]> >> >> 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 _______________________________________________ devel mailing list [email protected] http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
