From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Minchan Kim <minchan@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@kernel.org>
Subject: Re: [RFC PATCH v2 00/21] mm/zsmalloc: Split zsdesc from struct page
Date: Fri, 21 Jul 2023 06:52:05 +0900 [thread overview]
Message-ID: <CAB=+i9Quz9iP2-Lq=oQfKVVnzPDtOaKMm=hUPbnRg5hRxH+qaA@mail.gmail.com> (raw)
In-Reply-To: <CAJD7tkaXKLgWhOnGPXhs513kEZERyD6eX7btuU7f5dXuhWY62g@mail.gmail.com>
On Fri, Jul 21, 2023 at 6:39 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> <snip>
> >
> > > > > It seems to me though the sizeof(zsdesc) is actually 56 bytes (on
> > > > > 64-bit), so sizeof(zsdesc) + sizeof(memdesc) would be equal to the
> > > > > current size of struct page. If that's true, then there is no loss,
> > > >
> > > > Yeah, zsdesc would be 56 bytes on 64 bit CPUs as memcg_data field is
> > > > not used in zsmalloc.
> > > > More fields in the current struct page might not be needed in the
> > > > future, although it's hard to say at the moment.
> > > > but it's not a loss.
> > >
> > > Is page->memcg_data something that we can drop? Aren't there code
> > > paths that will check page->memcg_data even for kernel pages (e.g.
> > > __folio_put() -> __folio_put_small() -> mem_cgroup_uncharge() ) ?
> >
> > zsmalloc pages are not accounted for via __GFP_ACCOUNT,
>
> Yeah, but the code in the free path above will check page->memcg_data
> nonetheless to check if it is charged.
Right.
> I think to drop memcg_data we need to enlighten the code that some pages
> do not even have memcg_data at all
I agree with you. It should be one of the milestones for all of this to work.
It won't be complicated for the code to be aware of it, because there will be
a freeing (and uncharging if need) routine per type of descriptors.
next prev parent reply other threads:[~2023-07-20 21:52 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 4:20 Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 01/21] mm/zsmalloc: create new struct zsdesc Hyeonggon Yoo
2023-07-20 7:47 ` Sergey Senozhatsky
2023-07-13 4:20 ` [RFC PATCH v2 02/21] mm/zsmalloc: add utility functions for zsdesc Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 03/21] mm/zsmalloc: replace first_page to first_zsdesc in struct zspage Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 04/21] mm/zsmalloc: add alternatives of frequently used helper functions Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 05/21] mm/zsmalloc: convert {try,}lock_zspage() to use zsdesc Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 06/21] mm/zsmalloc: convert __zs_{map,unmap}_object() " Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 07/21] mm/zsmalloc: convert obj_to_location() and its users " Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 08/21] mm/zsmalloc: convert obj_malloc() " Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 09/21] mm/zsmalloc: convert create_page_chain() and its user " Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 10/21] mm/zsmalloc: convert obj_allocated() and related helpers " Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 11/21] mm/zsmalloc: convert init_zspage() " Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 12/21] mm/zsmalloc: convert obj_to_page() and zs_free() " Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 13/21] mm/zsmalloc: convert reset_page() to reset_zsdesc() Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 14/21] mm/zsmalloc: convert zs_page_{isolate,migrate,putback} to use zsdesc Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 15/21] mm/zsmalloc: convert __free_zspage() " Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 16/21] mm/zsmalloc: convert location_to_obj() " Hyeonggon Yoo
2023-07-20 7:49 ` Sergey Senozhatsky
2023-07-13 4:20 ` [RFC PATCH v2 17/21] mm/zsmalloc: convert migrate_zspage() " Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 18/21] mm/zsmalloc: convert get_zspage() to take zsdesc Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 19/21] mm/zsmalloc: convert SetZsPageMovable() to use zsdesc Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 20/21] mm/zsmalloc: remove now unused helper functions Hyeonggon Yoo
2023-07-13 4:20 ` [RFC PATCH v2 21/21] mm/zsmalloc: convert {get,set}_first_obj_offset() to use zsdesc Hyeonggon Yoo
2023-07-20 7:18 ` [RFC PATCH v2 00/21] mm/zsmalloc: Split zsdesc from struct page Sergey Senozhatsky
2023-07-20 7:54 ` Yosry Ahmed
2023-07-20 11:34 ` Hyeonggon Yoo
2023-07-20 18:31 ` Yosry Ahmed
2023-07-20 21:33 ` Hyeonggon Yoo
2023-07-20 21:38 ` Yosry Ahmed
2023-07-20 21:52 ` Hyeonggon Yoo [this message]
2023-07-20 21:57 ` Yosry Ahmed
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='CAB=+i9Quz9iP2-Lq=oQfKVVnzPDtOaKMm=hUPbnRg5hRxH+qaA@mail.gmail.com' \
--to=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=rppt@kernel.org \
--cc=senozhatsky@chromium.org \
--cc=willy@infradead.org \
--cc=yosryahmed@google.com \
/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