Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752026AbbHYEVp (ORCPT ); Tue, 25 Aug 2015 00:21:45 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:33507 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750699AbbHYEVo (ORCPT ); Tue, 25 Aug 2015 00:21:44 -0400 Date: Tue, 25 Aug 2015 13:22:24 +0900 From: Sergey Senozhatsky To: Dan Streetman Cc: Vlastimil Babka , Jonathan Corbet , Seth Jennings , Andrew Morton , "linux-doc@vger.kernel.org" , linux-kernel , Linux-MM Subject: Re: [PATCH] zswap: update docs for runtime-changeable attributes Message-ID: <20150825042224.GB412@swordfish> References: <1439924830-29275-1-git-send-email-ddstreet@ieee.org> <55D48C5E.7010004@suse.cz> <55D49A9F.7080105@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2517 Lines: 61 On (08/19/15 11:56), Dan Streetman wrote: [..] > > Ugh that's madness. Still, a documented madness is better than an undocumented one. > > heh, i'm not sure why it's madness, the alternative of > uncompressing/recompressing all pages into the new zpool and/or with > the new compressor seems much worse ;-) > Well, I sort of still think that 'change compressor and reboot' is OK. 5cents. > > > >>> > >>>> The zsmalloc type zpool has a more > >>>> +complex compressed page storage method, and it can achieve greater storage > >>>> +densities. However, zsmalloc does not implement compressed page eviction, so > >>>> +once zswap fills it cannot evict the oldest page, it can only reject new pages. > >>> > >>> I still wonder why anyone would use zsmalloc with zswap given this limitation. > >>> It seems only fine for zram which has no real swap as fallback. And even zbud > >>> doesn't have any shrinker interface that would react to memory pressure, so > >>> there's a possibility of premature OOM... sigh. > >> > >> for situations where zswap isn't expected to ever fill up, zsmalloc > >> will outperform zbud, since it has higher density. > > > > But then you could just use zram? :) > > well not *expected* to fill up doesn't mean it *won't* fill up :) > > > > >> 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 -ss -- 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/