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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>