From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758577Ab3BVR6Q (ORCPT ); Fri, 22 Feb 2013 12:58:16 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:33872 "EHLO e8.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757702Ab3BVR6O (ORCPT ); Fri, 22 Feb 2013 12:58:14 -0500 Message-ID: <5127B1AA.4080904@linux.vnet.ibm.com> Date: Fri, 22 Feb 2013 11:58:02 -0600 From: Seth Jennings User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joonsoo Kim CC: Andrew Morton , Greg Kroah-Hartman , Nitin Gupta , Minchan Kim , Konrad Rzeszutek Wilk , Dan Magenheimer , Robert Jennings , Jenifer Hopper , Mel Gorman , Johannes Weiner , Rik van Riel , Larry Woodman , Benjamin Herrenschmidt , Dave Hansen , Joe Perches , Cody P Schafer , linux-mm@kvack.org, linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org Subject: Re: [PATCHv6 1/8] zsmalloc: add to mm/ References: <1361397888-14863-1-git-send-email-sjenning@linux.vnet.ibm.com> <1361397888-14863-2-git-send-email-sjenning@linux.vnet.ibm.com> <20130222094001.GB8077@lge.com> In-Reply-To: <20130222094001.GB8077@lge.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13022217-9360-0000-0000-000010FD0C5C Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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