On 02/22/2013 03:40 AM, Joonsoo Kim wrote: > On Wed, Feb 20, 2013 at 04:04:41PM -0600, Seth Jennings wrote: >> ========= >> DO NOT MERGE, FOR REVIEW ONLY >> This patch introduces zsmalloc as new code, however, it already >> exists in drivers/staging. In order to build successfully, you >> must select EITHER to driver/staging version OR this version. >> Once zsmalloc is reviewed in this format (and hopefully accepted), >> I will create a new patchset that properly promotes zsmalloc from >> staging. >> ========= >> >> This patchset introduces 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. > > I have one more concern. It may be possibly stale question. > I think that zsmalloc makes system memories more fragmented. > Pages for zsmalloc can't be moved and may be spread at random location > because it's order is just 0, so high order allocation success rate > will be decreased. How do you think about it? For now, this is true. NUMA and migration awareness, IMO, are the highest priorities for additional development on zsmalloc (after merging). Thanks, Seth _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
