public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: 贺中坤 <hezhongkun.hzk@bytedance.com>
Cc: minchan@kernel.org, senozhatsky@chromium.org, mhocko@suse.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [External] Re: [RFC PATCH 1/3] zram: charge the compressed RAM to the page's memcgroup
Date: Thu, 15 Jun 2023 16:46:09 +0200	[thread overview]
Message-ID: <290d79bb-b1a6-3146-76a7-9938829e6ebe@redhat.com> (raw)
In-Reply-To: <CACSyD1NfbD_YBADH-3bR0=sGkrkEqxfgYLvyNyTiWdTvw2R6vA@mail.gmail.com>

On 15.06.23 15:40, 贺中坤 wrote:
>> 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.

Yes. But just to stress again, one issue I see is that if there is a 
page in the BIO that is not charged, you cannot charge the compressed page.

Assume you have some FS on that zram block device and  you want to make 
sure it gets properly charged to whoever is reading/writing a file on 
that filesystem. (imagine something like a compress shmem)

If a user (or the filesystem?) can trigger a BIO that has an uncharged 
page in it, it would not get charged accordingly.

The "easy" reproducer would have been O_DIRECT write() using the shared 
zeropage, but zram_write_page() is smart enough to optimize for that 
case (page_same_filled()). :)

Maybe I'm over-thinking this (well, the we do have partial I/O support, 
so something seems to be able to trigger such cases), and it would be 
great if someone with more FS->BIO experience could comment.

I'll note that this is fundamentally different to zswap, because with 
zswap you don't get arbitrary BIOs, you get an anon or shmem page (that 
should be charged).

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2023-06-15 14:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-15  3:48 [RFC PATCH 1/3] zram: charge the compressed RAM to the page's memcgroup Zhongkun He
2023-06-15  4:59 ` Yu Zhao
2023-06-15  8:57   ` Fabian Deutsch
2023-06-15 10:00     ` [External] " 贺中坤
2023-06-15 12:14       ` Fabian Deutsch
2023-06-16  1:39     ` Yosry Ahmed
2023-06-16  4:40       ` [External] " 贺中坤
2023-06-16  7:37         ` Yosry Ahmed
2023-06-16  7:57           ` David Hildenbrand
2023-06-16  8:04             ` Yosry Ahmed
2023-06-16  8:37               ` David Hildenbrand
2023-06-16  8:39                 ` Yosry Ahmed
2023-06-15  9:32   ` Fabian Deutsch
2023-06-15  9:41   ` [External] " 贺中坤
2023-06-15  9:27 ` David Hildenbrand
2023-06-15 11:15   ` [External] " 贺中坤
2023-06-15 11:19     ` David Hildenbrand
2023-06-15 12:19       ` 贺中坤
2023-06-15 12:56         ` David Hildenbrand
2023-06-15 13:40           ` 贺中坤
2023-06-15 14:46             ` David Hildenbrand [this message]
2023-06-16  3:44               ` 贺中坤
2023-06-15  9:35 ` Michal Hocko
2023-06-15 11:58   ` [External] " 贺中坤
2023-06-15 12:16     ` Michal Hocko
2023-06-15 13:09       ` 贺中坤
2023-06-15 13:27         ` Michal Hocko
2023-06-15 14:13           ` 贺中坤
2023-06-15 14:20             ` Michal Hocko
2023-06-16  3:31               ` 贺中坤
2023-06-16  6:40                 ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=290d79bb-b1a6-3146-76a7-9938829e6ebe@redhat.com \
    --to=david@redhat.com \
    --cc=hezhongkun.hzk@bytedance.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox