> Thanks Fabian for tagging me. > > I am not familiar with #1, so I will speak to #2. Zhongkun, There are > a few parts that I do not understand -- hopefully you can help me out > here: > > (1) If I understand correctly in this patch we set the active memcg > trying to charge any pages allocated in a zspage to the current memcg, > yet that zspage will contain multiple compressed object slots, not > just the one used by this memcg. Aren't we overcharging the memcg? > Basically the first memcg that happens to allocate the zspage will pay > for all the objects in this zspage, even after it stops using the > zspage completely? It will not overcharge. As you said below, we are not using __GFP_ACCOUNT and charging the compressed slots to the memcgs. > > (2) Patch 3 seems to be charging the compressed slots to the memcgs, > yet this patch is trying to charge the entire zspage. Aren't we double > charging the zspage? I am guessing this isn't happening because (as > Michal pointed out) we are not using __GFP_ACCOUNT here anyway, so > this patch may be NOP, and the actual charging is coming from patch 3 > only. YES， the actual charging is coming from patch 3. This patch just delivers the BIO page's memcg to the current task which is not the consumer. > > (3) Zswap recently implemented per-memcg charging of compressed > objects in a much simpler way. If your main interest is #2 (which is > what I understand from the commit log), it seems like zswap might be > providing this already? Why can't you use zswap? Is it the fact that > zswap requires a backing swapfile? Thanks for your reply and review. Yes, the zswap requires a backing swapfile. The I/O path is very complex, sometimes it will throttle the whole system if some resources are short , so we hope to use zram. > > Thanks! >
