linux-kernel - Re: [External] 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: <CACSyD1NfbD_YBADH-3bR0=sGkrkEqxfgYLvyNyTiWdTvw2R6vA@mail.gmail.com>
Date:   Thu, 15 Jun 2023 21:40:45 +0800
From:   贺中坤 <hezhongkun.hzk@...edance.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     minchan@...nel.org, senozhatsky@...omium.org, mhocko@...e.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [RFC PATCH 1/3] zram: charge the compressed RAM to
 the page's memcgroup

> I suspect for the swap->zram we should always get charged pages, because
> we're effectively writing out charged anon/shmem pages only -- without
> any buffer in between.

Hi David，the charged memory will be released in swap->zram. New pages
are allocated by alloc_zspage(), and we did not charge the page directly，but
the objects(like  slab), because the zspage are shared by any memcg.

>
> For the fs->zram or direct zram access device case I'm not so sure. It
> highly depends on what gets mapped into the bio (e.g., a kernel buffer,
> zeropage, ...). If it's a pagecache page, that should be charged and
> we're good. No so sure about fs metadata or some other fs cases (e.g.,
> write() to a file that bypass the pagecache).
>

Yes， the pagecaches are charged in fs->zram, but  will be released if
we drop the cache. the compressed objects are not charged.

> --
> Cheers,
>
> David / dhildenb
>