Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754718AbbHYGWH (ORCPT ); Tue, 25 Aug 2015 02:22:07 -0400 Received: from mx2.suse.de ([195.135.220.15]:39066 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751342AbbHYGWF (ORCPT ); Tue, 25 Aug 2015 02:22:05 -0400 Subject: Re: [PATCH] zswap: update docs for runtime-changeable attributes To: Sergey Senozhatsky , Dan Streetman References: <1439924830-29275-1-git-send-email-ddstreet@ieee.org> <55D48C5E.7010004@suse.cz> <55D49A9F.7080105@suse.cz> <20150825042224.GB412@swordfish> Cc: Jonathan Corbet , Seth Jennings , Andrew Morton , "linux-doc@vger.kernel.org" , linux-kernel , Linux-MM From: Vlastimil Babka Message-ID: <55DC098B.8080409@suse.cz> Date: Tue, 25 Aug 2015 08:22:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150825042224.GB412@swordfish> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1661 Lines: 36 On 25.8.2015 6:22, Sergey Senozhatsky wrote: >>>> i'd argue that neither zbud nor zsmalloc are responsible for reacting >>>> to memory pressure, they just store the pages. It's zswap that has to >>>> limit its size, which it does with max_percent_pool. >>> >>> Yeah but it's zbud that tracks the aging via LRU and reacts to reclaim requests >>> from zswap when zswap hits the limit. Zswap could easily add a shrinker that >>> would relay this requests in response to memory pressure as well. However, >>> zsmalloc doesn't implement the reclaim, or LRU tracking. >> >> I wrote a patch for zsmalloc reclaim a while ago: >> >> https://lwn.net/Articles/611713/ >> >> however it didn't make it in, due to the lack of zsmalloc LRU, or any >> proven benefit to zsmalloc reclaim. >> >> It's not really possible to add LRU to zsmalloc, by the nature of its >> design, using the struct page fields directly; there's no extra field >> to use as a lru entry. > > Just for information, zsmalloc now registers shrinker callbacks > > https://lkml.org/lkml/2015/7/8/497 Yeah but that's just for compaction, not freeing. I think that ideally zswap should track the LRU on the level of pages it receives as input, and then just tell zswap/zbud to free them. Then zswap would use its compaction to make sure that the reclaim results in actual freeing of page frames. Zbud could re-pair the orphaned half-pages to the same effect. -- 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/