On Tue, May 21, 2013 at 02:26:07PM +0800, Bob Liu wrote: > In my understanding, currenlty zswap have a few problems. > 1. The zswap pool size is 20% of total memory that's too random and once it > gets full the performance may even worse because everytime pageout() an anon > page two disk-io write ops may happend instead of one. Just to clarify, 20% is a default maximum amount that zswap can occupy. Also, in the steady over-the-limit state, the average number of writebacks is equal to the number of pages coming into zswap. The description above makes it sound like there is a reclaim amplification effect (two writebacks per zswap store) when, on average, there is none. The 2:1 effect only happens on one or two store operations right after the pool becomes full. This is unclear though, mostly because the pool limit is enforced in zswap. A situation exists where there might be an unbuddied zbud page with room for the upcoming allocation but, because we are over the pool limit, reclaim is done during that store anyway. I'm working on a clean way to fix that up, probably by moving the limit enforcement into zbud as suggested by Mel. > 2. The reclaim hook will only be triggered in frontswap_store(). > It may be result that the zswap pool size can't be adjusted in time which may > caused 20% memory lose for other users. > > This patch introduce a zswap shrinker, it make the balance that the zswap > pool size will be the same as anon pages in use. Using zbud, with 2 zpages per zbud page, that would mean that up to 2/3 of anon pages could be compressed while 1/3 remain uncompressed. How did you conclude that this is the right balance? If nr_reclaim in the shrinker became very large due to global_anon_pages_inuse suddenly dropping, we could be writing back a LOT of pages all at once. Having already looked at the patch, I can say that this isn't going to be the way to do this. I agree that there should be some sort of dynamic sizing, but IMHO using a shrinker isn't the way. Dave Chinner would not be happy about this since it is based on the zcache shrinker logic and he didn't have many kind words to say about it: https://lkml.org/lkml/2012/11/27/552 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>