Hi Luigi, On 08/19/2013 01:29 PM, Luigi Semenzato wrote: > > We are gearing up to evaluate zswap, but we have only ported kernels > up to 3.8 to our hardware, so we may be missing important patches. > > In our experience, and with all due respect, the linux MM is a complex > beast, and it's difficult to predict how hard it will be for us to > switch to zswap. Even with the relatively simple zram, our load I think it will be easy if zswap can also create a pseudo block device(I already done the simple implementation [PATCH 0/4] mm: merge zram into zswap), then it's transparent for original zram users. > triggered bugs in other parts of the MM that took a fair amount of > work to resolve. > > I may be wrong, but the in-memory compressed block device implemented > by zram seems like a simple device which uses a well-established API > to the rest of the kernel. If it is removed from the kernel, will it > be difficult for us to carry our own patch? Because we may have to do > that for a while. Of course we would prefer it if it stayed in, at > least temporarily. > > Also, could someone confirm or deny that the maximum compression ratio > in zbud is 2? Because we easily achieve a 2.6-2.8 compression ratio > with our loads using zram with zsmalloc and LZO or snappy. Losing > that memory will cause a noticeable regression, which will encourage > us to stick with zram. > > I am hoping that our load is not so unusual that we are the only Linux > users in this situation, and that zsmalloc (or other > allocator-compressor with similar characteristics) will continue to > exist, whether it is used by zram or zswap. > > Thanks! > -- Regards, -Bob -- 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>