linux-kernel - Re: [PATCH 0/5] staging: zsmalloc: memory allocator for compressed pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Jan 2012 14:03:44 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>,
	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Brian King <brking@...ux.vnet.ibm.com>,
	Nitin Gupta <ngupta@...are.org>,
	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 0/5] staging: zsmalloc: memory allocator for compressed
 pages

On Mon,  9 Jan 2012 16:51:55 -0600
Seth Jennings <sjenning@...ux.vnet.ibm.com> wrote:

> This patchset introduces a new memory allocation library named
> zsmalloc.  zsmalloc was designed to fulfill the needs
> of users where:
>  1) Memory is constrained, preventing contiguous page allocations
>     larger than order 0 and
>  2) Allocations are all/commonly greater than half a page.
> 
> In a generic allocator, an allocation set like this would
> cause high fragmentation.  The allocations can't span non-
> contiguous page boundaries; therefore, the part of the page
> unused by each allocation is wasted.
> 
> zsmalloc is a slab-based allocator that uses a non-standard
> malloc interface, requiring the user to map the allocation
> before accessing it. This allows allocations to span two
> non-contiguous pages using virtual memory mapping, greatly
> reducing fragmentation in the memory pool.

The changelog doesn't really describe why the code was written and
provides no reason for anyone to merge it.

Perhaps the reason was to clean up and generalise the zram xvmalloc
code.  Perhaps the reason was also to then use zsmalloc somewhere else
in the kernel.  But I really don't know.  This is the most important
part of the patch description and you completely omitted it!


Where will this code live after it escapes from drivers/staging/? mm/?
--
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/