Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752451Ab3EaBu3 (ORCPT ); Thu, 30 May 2013 21:50:29 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:30139 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750842Ab3EaBuZ (ORCPT ); Thu, 30 May 2013 21:50:25 -0400 Message-ID: <51A8015C.6020402@oracle.com> Date: Fri, 31 May 2013 09:48:12 +0800 From: Bob Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Seth Jennings CC: Andrew Morton , Mel Gorman , Dan Magenheimer , Greg Kroah-Hartman , Nitin Gupta , Minchan Kim , Konrad Wilk , Robert Jennings , Jenifer Hopper , Johannes Weiner , Rik van Riel , Larry Woodman , Benjamin Herrenschmidt , Dave Hansen , Joe Perches , Joonsoo Kim , Cody P Schafer , Hugh Dickens , Paul Mackerras , Heesub Shin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org Subject: Re: [PATCHv12 2/4] zbud: add to mm/ References: <1369067168-12291-1-git-send-email-sjenning@linux.vnet.ibm.com> <1369067168-12291-3-git-send-email-sjenning@linux.vnet.ibm.com> <20130528145911.bd484cbb0bb7a27c1623c520@linux-foundation.org> <20130529154500.GB428@cerebellum> <20130529113434.b2ced4cc1e66c7a0a520d908@linux-foundation.org> <20130529204236.GD428@cerebellum> <20130529134835.58dd89774f47205da4a06202@linux-foundation.org> <754ae8a0-23af-4c87-953f-d608cba84191@default> <20130529142904.ace2a29b90a9076d0ee251fd@linux-foundation.org> <20130530174344.GA15837@medulla> <20130530212017.GB15837@medulla> In-Reply-To: <20130530212017.GB15837@medulla> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1202 Lines: 38 Hi Seth, On 05/31/2013 05:20 AM, Seth Jennings wrote: > Andrew, Mel, > > This struct page stuffing is taking a lot of time to work out and _might_ be > fraught with peril when memmap peekers are considered. > > What do you think about just storing the zbud page metadata inline in the > memory page in the first zbud page chunk? How about making zswap based on SLAB? Create a PAGE_SIZE slab and when zswap need to alloc_page() using kmem_cache_alloc() instead. So that leave SLAB layer to handler the NUMA problem and do the dynamical pool size for us. In this way, an extra struct need to manage the zbud page metadate instead of using struct page. But I think it's easy and won't occupy many memory. > > Mel, this kinda hurts you plans for making NCHUNKS = 2, since there would > only be one chunk available for storage and would make zbud useless. > > Just a way to sidestep this whole issue. What do you think? > > Seth > -- Regards, -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/