From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758793Ab3BGQPf (ORCPT ); Thu, 7 Feb 2013 11:15:35 -0500 Received: from e38.co.us.ibm.com ([32.97.110.159]:60692 "EHLO e38.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757809Ab3BGQPe (ORCPT ); Thu, 7 Feb 2013 11:15:34 -0500 Message-ID: <5113D291.2020903@linux.vnet.ibm.com> Date: Thu, 07 Feb 2013 10:13:05 -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: Lord Glauber Costa of Sealand CC: Rik van Riel , Greg Kroah-Hartman , Andrew Morton , Nitin Gupta , Minchan Kim , Konrad Rzeszutek Wilk , Dan Magenheimer , Robert Jennings , Jenifer Hopper , Mel Gorman , Johannes Weiner , Larry Woodman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org Subject: Re: [PATCHv2 8/9] zswap: add to mm/ References: <1357590280-31535-1-git-send-email-sjenning@linux.vnet.ibm.com> <1357590280-31535-9-git-send-email-sjenning@linux.vnet.ibm.com> <51030ADA.8030403@redhat.com> <510698F5.5060205@linux.vnet.ibm.com> <5107A2B8.4070505@parallels.com> In-Reply-To: <5107A2B8.4070505@parallels.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13020716-5518-0000-0000-00000B5FB5EC Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/29/2013 04:21 AM, Lord Glauber Costa of Sealand wrote: > On 01/28/2013 07:27 PM, Seth Jennings wrote: >> Yes, I prototyped a shrinker interface for zswap, but, as we both >> figured, it shrinks the zswap compressed pool too aggressively to the >> point of being useless. > Can't you advertise a smaller number of objects that you actively have? Thanks for looking at the code! An interesting idea. I'm just not sure how you would manage the underlying policy of how aggressively does zswap allow itself to be shrunk? The fact that zswap _only_ operates under memory pressure makes that policy difficult, because it is under continuous shrinking pressure, unlike other shrinkable caches in the kernel that spend most of their time operating in unconstrained or lightly/intermittently strained conditions. Thanks, Seth