On 2014-01-22 19:18, Minchan Kim wrote: > > From the beginning, zswap is for reducing swap I/O but if workingset > overflows, it should write back rather than OOM with expecting a small > number of writeback would make the system happy because the high memory > pressure is temporal so soon most of workload would be hit in zswap > without further writeback. > But write-through would still reduce I/O to swap, the only difference is that it just reduces the need to read from swap, not the need for all I/O. This can still be significant because it would mean (assuming that zswap uses a LRU algorithm for deciding what to drop) that static pages that get accessed frequently and get swapped out often would just get written to swap once, and only be read from zswap. Also, I disagree with the implication that memory pressure is short-lived, I have a desktop with 16G of RAM, and I regularly work with data-sets that are at-least that size (mostly hi-res images and hi-quality video/audio). > If memory pressure continues and writeback steadily, it means zswap's > benefit would be mitigated, even worse by addding comp/decomp overhead. > In that case, it would be better to disable zswap, even. > > Dan said writethrough supporting is first step to make zswap smart > but anybody didn't say further words to step into the smart and > what's the *real* workload want it and what's the *real* number from > that because dm-cache/zram might be a good fit. > (I don't intend to argue zram VS zswap. If the concern is solved by > existing solution, why should we invent new function and > have maintenace cost?) so it's very hard for me to judge that we should > accept and maintain it. bcache isn't stable enough that I would even trust using it for /tmp, let alone using it for swap (i consistently get kernel OOPSes when it's compiled in or loaded as a module, even when I'm not using it), and dm-cache is a pain to setup (especially if it needs to happen every time the system boots). Part of the big advantage of zswap is that it is (relatively) stable, and all it takes to set it up is turning on a pair of kconfig options. > We need blueprint for the future and make an agreement on the > direction before merging this patch. > > But code size is not much and Seth already gave an his Ack so I don't > want to hurt Dan any more(Sorry for Dan) and wasting my time so pass > the decision to others(ex, Seth and Bob). > If they insist on, I don't object any more. > > Sorry for bothering Dan. > > Thanks. -- 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>