Re: [PATCH] zswap: update docs for runtime-changeable attributes

[Vlastimil Babka]

On 08/19/2015 04:21 PM, Dan Streetman wrote:
> On Wed, Aug 19, 2015 at 10:02 AM, Vlastimil Babka <vbabka@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/