On Thu, Jun 15, 2023 at 5:27 PM David Hildenbrand <david@xxxxxxxxxx> wrote: > > Interesting. When looking at possible ways to achieve that in a clean > way, my understanding was that the page might not always be accounted to > a memcg (e.g., simply some buffer?). Besides the swap->zram case I was > thinking about other fs->zram case, or just a straight read/write to the > zram device. > > The easiest way to see where that goes wrong I think is > zram_bvec_write_partial(), where we simply allocate a temporary page. > > Either I am missing something important, or this only works in some > special cases. > > I came to the conclusion that the only reasonable way is to assign a > complete zram device to a single cgroup and have all memory accounted to > that cgroup. Does also not solve all use cases (especially the > swap->zram case that might be better offjust using zswap?) but at least > the memory gets accounted in a more predictable way. > > Happy to learn more. > > -- > Cheers, > > David / dhildenb > Hi david, thanks for your reply. This should be my mistake, I didn't describe the problem clearly. The reason for the problem is not the temporary page allocated at the beginning of zram_bvec_write_partial() and released at the end,but the compressed memory allocated by zs_malloc() in zram_write_page(). So, it may not meet the need to assign a complete zram device to a single cgroup. we need to charge the compressed memory to the original page's memory cgroup, which is not charged so far.
