> From: Seth Jennings [mailto:sjenning@xxxxxxxxxxxxxxxxxx] > Subject: [PATCHv2 8/9] zswap: add to mm/ > > zswap is a thin compression backend for frontswap. It receives > pages from frontswap and attempts to store them in a compressed > memory pool, resulting in an effective partial memory reclaim and > dramatically reduced swap device I/O. > > Additional, in most cases, pages can be retrieved from this > compressed store much more quickly than reading from tradition > swap devices resulting in faster performance for many workloads. > > This patch adds the zswap driver to mm/ > > Signed-off-by: Seth Jennings <sjenning@xxxxxxxxxxxxxxxxxx> I've implemented the equivalent of zswap_flush_* in zcache. It looks much better than my earlier attempt at similar code to move zpages to swap. Nice work and thanks! But... (isn't there always a "but";-)... > +/* > + * This limits is arbitrary for now until a better > + * policy can be implemented. This is so we don't > + * eat all of RAM decompressing pages for writeback. > + */ > +#define ZSWAP_MAX_OUTSTANDING_FLUSHES 64 > + if (atomic_read(&zswap_outstanding_flushes) > > + ZSWAP_MAX_OUTSTANDING_FLUSHES) > + return; >From what I can see, zcache is in some ways more aggressive in some circumstances in "flushing" (zcache calls it "unuse"), and in some ways less aggressive. But with significant exercise, I can always cause the kernel to OOM when it is under heavy memory pressure and the flush/unuse code is being used. Have you given any further thought to "a better policy" (see the comment in the snippet above)? I'm going to try a smaller number than 64 to see if the OOMs go away, but choosing a random number for this throttling doesn't seem like a good plan for moving forward. Thanks, Dan P.S. I know you, like I, often use something kernbench-ish to exercise your code. I've found that compiling a kernel, then switching to another kernel directory, doing a git pull, and compiling that kernel, causes a lot of flushes/unuses and the OOMs. (This with 1GB RAM booting RHEL6 with a full GUI.) _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
