Message-ID: <5126DE7B.2010203@gmail.com>
Date:	Fri, 22 Feb 2013 10:56:59 +0800
From:	Ric Mason <ric.masonn@...il.com>
To:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Nitin Gupta <ngupta@...are.org>,
	Minchan Kim <minchan@...nel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Robert Jennings <rcj@...ux.vnet.ibm.com>,
	Jenifer Hopper <jhopper@...ibm.com>,
	Mel Gorman <mgorman@...e.de>,
	Johannes Weiner <jweiner@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Larry Woodman <lwoodman@...hat.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Joe Perches <joe@...ches.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org
Subject: Re: [PATCHv5 2/8] zsmalloc: add documentation

On 02/21/2013 11:50 PM, Seth Jennings wrote:
> On 02/21/2013 02:49 AM, Ric Mason wrote:
>> On 02/19/2013 03:16 AM, Seth Jennings wrote:
>>> On 02/16/2013 12:21 AM, Ric Mason wrote:
>>>> On 02/14/2013 02:38 AM, Seth Jennings wrote:
>>>>> This patch adds a documentation file for zsmalloc at
>>>>> Documentation/vm/zsmalloc.txt
>>>>>
>>>>> Signed-off-by: Seth Jennings <sjenning@...ux.vnet.ibm.com>
>>>>> ---
>>>>>     Documentation/vm/zsmalloc.txt |   68
>>>>> +++++++++++++++++++++++++++++++++++++++++
>>>>>     1 file changed, 68 insertions(+)
>>>>>     create mode 100644 Documentation/vm/zsmalloc.txt
>>>>>
>>>>> diff --git a/Documentation/vm/zsmalloc.txt
>>>>> b/Documentation/vm/zsmalloc.txt
>>>>> new file mode 100644
>>>>> index 0000000..85aa617
>>>>> --- /dev/null
>>>>> +++ b/Documentation/vm/zsmalloc.txt
>>>>> @@ -0,0 +1,68 @@
>>>>> +zsmalloc Memory Allocator
>>>>> +
>>>>> +Overview
>>>>> +
>>>>> +zmalloc a new slab-based memory allocator,
>>>>> +zsmalloc, for storing compressed pages.  It is designed for
>>>>> +low fragmentation and high allocation success rate on
>>>>> +large object, but <= PAGE_SIZE allocations.
>>>>> +
>>>>> +zsmalloc differs from the kernel slab allocator in two primary
>>>>> +ways to achieve these design goals.
>>>>> +
>>>>> +zsmalloc never requires high order page allocations to back
>>>>> +slabs, or "size classes" in zsmalloc terms. Instead it allows
>>>>> +multiple single-order pages to be stitched together into a
>>>>> +"zspage" which backs the slab.  This allows for higher allocation
>>>>> +success rate under memory pressure.
>>>>> +
>>>>> +Also, zsmalloc allows objects to span page boundaries within the
>>>>> +zspage.  This allows for lower fragmentation than could be had
>>>>> +with the kernel slab allocator for objects between PAGE_SIZE/2
>>>>> +and PAGE_SIZE.  With the kernel slab allocator, if a page compresses
>>>>> +to 60% of it original size, the memory savings gained through
>>>>> +compression is lost in fragmentation because another object of
>>>>> +the same size can't be stored in the leftover space.
>>>>> +
>>>>> +This ability to span pages results in zsmalloc allocations not being
>>>>> +directly addressable by the user.  The user is given an
>>>>> +non-dereferencable handle in response to an allocation request.
>>>>> +That handle must be mapped, using zs_map_object(), which returns
>>>>> +a pointer to the mapped region that can be used.  The mapping is
>>>>> +necessary since the object data may reside in two different
>>>>> +noncontigious pages.
>>>> Do you mean the reason of  to use a zsmalloc object must map after
>>>> malloc is object data maybe reside in two different nocontiguous pages?
>>> Yes, that is one reason for the mapping.  The other reason (more of an
>>> added bonus) is below.
>>>
>>>>> +
>>>>> +For 32-bit systems, zsmalloc has the added benefit of being
>>>>> +able to back slabs with HIGHMEM pages, something not possible
>>>> What's the meaning of "back slabs with HIGHMEM pages"?
>>> By HIGHMEM, I'm referring to the HIGHMEM memory zone on 32-bit systems
>>> with larger that 1GB (actually a little less) of RAM.  The upper 3GB
>>> of the 4GB address space, depending on kernel build options, is not
>>> directly addressable by the kernel, but can be mapped into the kernel
>>> address space with functions like kmap() or kmap_atomic().
>>>
>>> These pages can't be used by slab/slub because they are not
>>> continuously mapped into the kernel address space.  However, since
>>> zsmalloc requires a mapping anyway to handle objects that span
>>> non-contiguous page boundaries, we do the kernel mapping as part of
>>> the process.
>>>
>>> So zspages, the conceptual slab in zsmalloc backed by single-order
>>> pages can include pages from the HIGHMEM zone as well.
>> Thanks for your clarify,
>>   http://lwn.net/Articles/537422/, your article about zswap in lwn.
>>   "Additionally, the kernel slab allocator does not allow objects that
>> are less
>> than a page in size to span a page boundary. This means that if an
>> object is
>> PAGE_SIZE/2 + 1 bytes in size, it effectively use an entire page,
>> resulting in
>> ~50% waste. Hense there are *no kmalloc() cache size* between
>> PAGE_SIZE/2 and
>> PAGE_SIZE."
>> Are your sure? It seems that kmalloc cache support big size, your can
>> check in
>> include/linux/kmalloc_sizes.h
> Yes, kmalloc can allocate large objects > PAGE_SIZE, but there are no
> cache sizes _between_ PAGE_SIZE/2 and PAGE_SIZE.  For example, on a
> system with 4k pages, there are no caches between kmalloc-2048 and
> kmalloc-4096.

kmalloc object > PAGE_SIZE/2 or > PAGE_SIZE should also allocate from 
slab cache, correct? Then how can alloc object w/o slab cache which 
contains this object size objects?

>
> Seth
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

--
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