Re: [PATCH 0/8] zswap: compressed swap caching

[Seth Jennings]

Hey Luigi,

To echo Dan, it'd be great if we could move this discussion to a new
thread as to leaving this one for code review/comments.  But I did
want to respond.

On 12/12/2012 04:49 PM, Luigi Semenzato wrote:
> Just a couple of questions and comments as a user.  I apologize if
> this is the wrong time to make them, feel free to ignore them.
> 
> 1. It's becoming difficult to understand how zcache, zcache2, zram,
> and now zswap, interact and/or overlap with each other.  For instance,
> I am examining the possibility of using zcache2 and zram in parallel.
> Should I also/instead consider zswap, using a plain RAM disk as the
> swap device?

I guess the short answer is:
* Zcache is no more, replaced by zcache2 (so I stop making the
distinction)
* You wouldn't use zcache and zswap together unless you first disabled
the frontswap part of zcache, however this configuration isn't
recommended since there would be no cooperation between the compressed
page cache and compressed swap cache.
* Zram could work with either zswap or zcache although the
interactions would be interesting; namely, I think zram stores would
likely fail with high frequency since the primary reason the page
would not be captured by either zswap or zcache before it reaches zram
is that zswap/zcache was unable to allocate space.  So zram would
likely fail for the same reason, causing swap slots to be marked as
bad and rapidly shrink the effective size of the zram device.

> 2. Zswap looks like a two-stage swap device, with one stage being
> compressed memory.  I don't know if and where the abstraction breaks,
> and what the implementation issues would be, but I would find it
> easier to view and configure this as a two-stage swap, where one stage
> is chosen as zcache (but could be something else).

I didn't follow this.

> 3. As far as I can tell, none of these compressors has a good way of
> balancing the amount of memory dedicated to compression against the
> pressure on the rest of the memory.  On both zram and zswap, we set a
> max size for the compressed data.  That size determines how much RAM
> is left for the working set, which should remain uncompressed.  But
> the size of the working set can vary significantly with the load.  If
> we choose the size based on a worst-case working set, we'll be
> underutilizing RAM on average.  If we choose it smaller than that, the
> worst-case working set will cause excessive CPU use and thrashing.

This kind of adaptive tuning would be hard to implement and even
harder to get right for everyone, if it could be done at all.
However, one way to achieve this would be to have something in
userspace periodically change the sysfs attribute that controls
maximum compressed pool size based on your own policy.  Both zswap and
zcache have this tunable.

Seth

--
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/