linux-kernel - Re: [RFC PATCH 1/3] zram: charge the compressed RAM to the page's memcgroup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d9b22eaa-00a1-6c5c-99a0-126b085f7cb0@redhat.com>
Date:   Thu, 15 Jun 2023 11:27:00 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Zhongkun He <hezhongkun.hzk@...edance.com>, minchan@...nel.org,
        senozhatsky@...omium.org, mhocko@...e.com
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/3] zram: charge the compressed RAM to the page's
 memcgroup

On 15.06.23 05:48, Zhongkun He wrote:
> The compressed RAM is currently charged to kernel, not to
> any memory cgroup, which is not satisfy our usage scenario.
> if the memory of a task is limited by memcgroup, it will
> swap out the memory to zram swap device when the memory
> is insufficient. In that case, the memory limit will have
> no effect.
> 
> So, it should makes sense to charge the compressed RAM to
> the page's memory cgroup.

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