On 02/21/2013 08:56 PM, Ric Mason wrote: > 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@xxxxxxxxxxxxxxxxxx> >>>>>> --- >>>>>> 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? I have to admit, I didn't understand the question. Thanks, Seth _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
