From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: akpm@linux-foundation.org, vbabka@suse.cz, willy@infradead.org,
linux-mm@kvack.org
Subject: Re: [PATCH -mm 0/2] mm: page_ext: split page_ext flags
Date: Sun, 18 Dec 2022 17:08:27 +0900 [thread overview]
Message-ID: <Y57Ke7RTtUJi0Pep@hyeyoo> (raw)
In-Reply-To: <20221217105833.24851-1-laoar.shao@gmail.com>
On Sat, Dec 17, 2022 at 10:58:31AM +0000, Yafang Shao wrote:
> On 64bit system, page extension is for debugging purpose only currently,
> because of its overhead, in particular the memory overhead.
>
> Once a page_ext is enabled, at least it will take 0.2% of the total
> memory because of the page_ext flags, no matter this page_ext uses it or
> not. Currently this page_ext flags is only used for page_owner on 64bit
> system. So it doesn't make sense to allocate this flags for all page_ext
> by default. We'd better move it into page_owner's structure, then when
> someone wants to introduce a new page_ext which may be memory-overhead
> sensitive, it will save this unneeded overhead.
I'm still worried about the approach of using page_ext for BPF memory
accounting.
Let's say we finally accepted the approach of using page_ext for BPF memory
accounting, and if it's not enabled by default, you need to rebuild the kernel
when you want to check BPF memory usage. (Or make everyone bear the overhead
by enabling page_ext default for BPF memory accounting that one may not be interested)
How the problem of accounting kfree_rcu() is going?
Doesn't call_rcu() work for the problem?
I still think it's much more feasible.
> On 32bit system, there's page_idle running on production envrionment,
> which also uses this page_ext flags. So it will take another 0.2% of
> total memory if the user enable both page_idle and page_owner after this
> change, but considering page_owner is for debugging purpose only, the
> memory overhead in this case won't be a problem.
>
> So, let split the page_ext flags.
>
> Yafang Shao (2):
> mm: page_owner: split page_owner's flag from the comm flags
> mm: page_idle: split 32bit page_idle's flag from the common flags
>
> include/linux/page_ext.h | 14 +-------------
> include/linux/page_idle.h | 39 +++++++++++++++++++++++++++++++++------
> mm/page_ext.c | 10 ----------
> mm/page_idle.c | 12 ++++++++++++
> mm/page_owner.c | 36 ++++++++++++++++++++++--------------
> 5 files changed, 68 insertions(+), 43 deletions(-)
>
> --
> 2.30.1 (Apple Git-130)
>
--
Thanks,
Hyeonggon
next prev parent reply other threads:[~2022-12-18 8:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-17 10:58 Yafang Shao
2022-12-17 10:58 ` [PATCH -mm 1/2] mm: page_owner: split page_owner's flag from the comm flags Yafang Shao
2022-12-17 10:58 ` [PATCH -mm 2/2] mm: page_idle: split 32bit page_idle's flag from the common flags Yafang Shao
2022-12-17 12:45 ` kernel test robot
2022-12-17 13:59 ` Yafang Shao
2022-12-17 12:45 ` kernel test robot
2022-12-18 8:08 ` Hyeonggon Yoo [this message]
2022-12-18 10:01 ` [PATCH -mm 0/2] mm: page_ext: split page_ext flags Yafang Shao
2022-12-18 11:22 ` Hyeonggon Yoo
2023-01-16 10:58 ` Vlastimil Babka
2023-01-18 3:15 ` Yafang Shao
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=Y57Ke7RTtUJi0Pep@hyeyoo \
--to=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=laoar.shao@gmail.com \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
--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