Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932233AbbHSPDA (ORCPT ); Wed, 19 Aug 2015 11:03:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:49177 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932137AbbHSPC7 (ORCPT ); Wed, 19 Aug 2015 11:02:59 -0400 Subject: Re: [PATCH] zswap: update docs for runtime-changeable attributes To: Dan Streetman References: <1439924830-29275-1-git-send-email-ddstreet@ieee.org> <55D48C5E.7010004@suse.cz> Cc: Jonathan Corbet , Seth Jennings , Andrew Morton , "linux-doc@vger.kernel.org" , linux-kernel , Linux-MM From: Vlastimil Babka X-Enigmail-Draft-Status: N1110 Message-ID: <55D49A9F.7080105@suse.cz> Date: Wed, 19 Aug 2015 17:02:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3019 Lines: 61 On 08/19/2015 04:21 PM, Dan Streetman wrote: > On Wed, Aug 19, 2015 at 10:02 AM, Vlastimil Babka wrote: >> On 08/18/2015 09:07 PM, Dan Streetman wrote: >>> +pages are freed. The pool is not preallocated. By default, a zpool of type >>> +zbud is created, but it can be selected at boot time by setting the "zpool" >>> +attribute, e.g. zswap.zpool=zbud. It can also be changed at runtime using the >>> +sysfs "zpool" attribute, e.g. >>> + >>> +echo zbud > /sys/module/zswap/parameters/zpool >> >> What exactly happens if zswap is already being used and has allocated pages in >> one type of pool, and you're changing it to the other one? > > zswap has a rcu list where each entry contains a specific compressor > and zpool. When either the compressor or zpool is changed, a new > entry is created with a new compressor and pool and put at the front > of the list. New pages always use the "current" (first) entry. Any > old (unused) entries are freed whenever all the pages they contain are > removed. > > So when the compressor or zpool is changed, the only thing that > happens is zswap creates a new compressor and zpool and places it at > the front of the list, for new pages to use. No existing pages are > touched. Ugh that's madness. Still, a documented madness is better than an undocumented one. >> >>> 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? :) > 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. One could also argue that aging should be tracked in zswap, and it would just tell zbud/zmalloc to drop a specific compressed page. But that wouldn't reliably translate into freeing of page frames... -- 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/