From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755104Ab3ADPze (ORCPT ); Fri, 4 Jan 2013 10:55:34 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:58730 "EHLO e9.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755080Ab3ADPzb (ORCPT ); Fri, 4 Jan 2013 10:55:31 -0500 Message-ID: <50E6FB66.7020805@linux.vnet.ibm.com> Date: Fri, 04 Jan 2013 09:55:18 -0600 From: Seth Jennings User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dave Chinner CC: Dan Magenheimer , Dave Hansen , Greg Kroah-Hartman , Andrew Morton , Nitin Gupta , Minchan Kim , Konrad Wilk , Robert Jennings , Jenifer Hopper , Mel Gorman , Johannes Weiner , Rik van Riel , Larry Woodman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org Subject: Re: [PATCH 7/8] zswap: add to mm/ References: <1355262966-15281-1-git-send-email-sjenning@linux.vnet.ibm.com> <1355262966-15281-8-git-send-email-sjenning@linux.vnet.ibm.com> <0e91c1e5-7a62-4b89-9473-09fff384a334@default> <50E32255.60901@linux.vnet.ibm.com> <50E4588E.6080001@linux.vnet.ibm.com> <28a63847-7659-44c4-9c33-87f5d50b2ea0@default> <50E479AD.9030502@linux.vnet.ibm.com> <9955b9e0-731b-4cbf-9db0-683fcd32f944@default> <20130103073339.GF3120@dastard> <20130104023030.GK3120@dastard> In-Reply-To: <20130104023030.GK3120@dastard> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13010415-7182-0000-0000-00000432A253 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/03/2013 08:30 PM, Dave Chinner wrote: >>> And so the two subsystems need different reclaim implementations. >>> > > And, well, that's exactly what we have shrinkers for - implmenting >>> > > subsystem specific reclaim policy. The shrinker infrastructure is >>> > > responsible for them keeping balance between all the caches that >>> > > have shrinkers and the size of the page cache... >> > >> > Given the above, do you think either compressed-anonymous-pages or >> > compressed-pagecache-pages are suitable candidates for the shrinker >> > infrastructure? > I don't know all the details of what you are trying to do, but you > seem to be describing a two-level heirarchy - a pool of compressed > data and a pool of uncompressed data, and under memory pressure are > migrating data from the uncompressed pool to the compressed pool. On > access, you are migrating back the other way. Hence it seems to me > that you could implement the process of migration from the > uncompressed pool to the compressed pool as a shrinker so that it > only happens as a result of memory pressure.... In our case, the mechanism for moving pages from the uncompressed pool (anonymous memory) to the compressed pool is the swapping mechanism itself. The mechanism for moving pages the other way is the page fault handler. To summarize my ideas wrt to zswap and the shrinker interface, I don't think there is a good use case here because all of the compressed pages in zswap are conceptually dirty. The writeback for these pages is both slow (bio write) and requires memory allocation. So zswap isn't a cache in the usual sense, where cache contents are clean, exist in RAM only for performance reasons, and can be freed in a lightweight way at any time. Thanks, Seth