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: <bd119703-7b7b-c4ab-0c38-9b85809de252@redhat.com>
Date:   Thu, 15 Jun 2023 14:56:55 +0200
From:   David Hildenbrand <david@...hat.com>
To:     贺中坤 <hezhongkun.hzk@...edance.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

On 15.06.23 14:19, 贺中坤 wrote:
> On Thu, Jun 15, 2023 at 7:19 PM David Hildenbrand <david@...hat.com> wrote:
>>
>> Yes, but my point is that there are cases where the pages you get are
>> not charged. zram_bvec_write_partial() is just one such example that
>> highlights the issue.
> 
> Sorry ,I got it.

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.

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).

-- 
Cheers,

David / dhildenb