From: Michal Hocko <mhocko@suse.com>
To: lizhe.67@bytedance.com
Cc: akpm@linux-foundation.org, vbabka@suse.cz, mhiramat@kernel.org,
keescook@chromium.org, Jason@zx2c4.com,
mark-pk.tsai@mediatek.com, rostedt@goodmis.org, corbet@lwn.net,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, lizefan.x@bytedance.com,
yuanzhu@bytedance.com
Subject: Re: [PATCH v3] page_ext: introduce boot parameter 'early_page_ext'
Date: Thu, 25 Aug 2022 09:11:29 +0200 [thread overview]
Message-ID: <YwcgoZfw4RhZ1Bl6@dhcp22.suse.cz> (raw)
In-Reply-To: <20220825063102.92307-1-lizhe.67@bytedance.com>
On Thu 25-08-22 14:31:02, lizhe.67@bytedance.com wrote:
> From: Li Zhe <lizhe.67@bytedance.com>
>
> In 'commit 2f1ee0913ce5 ("Revert "mm: use early_pfn_to_nid in page_ext_init"")',
> we call page_ext_init() after page_alloc_init_late() to avoid some panic
> problem. It seems that we cannot track early page allocations in current
> kernel even if page structure has been initialized early.
>
> This patch introduce a new boot parameter 'early_page_ext' to resolve this
> problem. If we pass it to kernel, function page_ext_init() will be moved
> up and feature 'deferred initialization of struct pages' will be disabled.
will be disabled to initialize the page allocator early and prevent from
the OOM mentioned above.
> It can help us to catch early page allocations. This is useful especially
> when we find that the free memory value is not the same right after
> different kernel booting.
>
> Changelogs:
>
> v1->v2:
> - use a cmd line parameter to move up function page_ext_init() instead of
> using CONFIG_DEFERRED_STRUCT_PAGE_INIT
> - fix oom problem[1]
>
> v2->v3:
> - make adjustments suggested by Michal Hocko
>
> v1 patch: https://lore.kernel.org/lkml/Yv3r6Y1vh+6AbY4+@dhcp22.suse.cz/T/
> v2 patch: https://lore.kernel.org/lkml/20220824065058.81051-1-lizhe.67@bytedance.com/T/
>
> [1]: https://lore.kernel.org/linux-mm/YwHmXLu5txij+p35@xsang-OptiPlex-9020/
the changelog is usually not part of the changelog and goes under ---
>
> Suggested-by: Michal Hocko <mhocko@suse.com>
> Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
I still have few comments below before I am going to ack. But this looks
much better already.
> ---
> Documentation/admin-guide/kernel-parameters.txt | 6 ++++++
> include/linux/page_ext.h | 11 +++++++++++
> init/main.c | 6 +++++-
> mm/page_alloc.c | 2 ++
> mm/page_ext.c | 12 ++++++++++++
> 5 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index d7f30902fda0..7b5726828ac0 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1471,6 +1471,12 @@
> Permit 'security.evm' to be updated regardless of
> current integrity status.
>
> + early_page_ext [KNL] Boot-time early page_ext initializing option.
> + This boot parameter disables the deferred initialization
> + of struct page and move up function page_ext_init() in
> + order to catch early page allocations. Available with
> + CONFIG_PAGE_EXTENSION=y.
For admins it would likely be more easier to understand something like
following
early_page_ext [KNL] Enforces page_ext initialization to earlier
stages so cover more early boot allocations.
Please note that as side effect some
optimizations might be disabled to achieve that
(e.g. parallelized memory initialization is
disabled) so the boot process might take longer,
especially on systems with a lot of memory.
Available with CONFIG_PAGE_EXTENSION=y
[...]
> diff --git a/mm/page_ext.c b/mm/page_ext.c
> index 3dc715d7ac29..bf4f2a12d7dc 100644
> --- a/mm/page_ext.c
> +++ b/mm/page_ext.c
> @@ -85,6 +85,18 @@ unsigned long page_ext_size = sizeof(struct page_ext);
>
> static unsigned long total_usage;
>
> +#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
> +bool early_page_ext __meminitdata;
> +#else
> +bool early_page_ext __meminitdata = true;
> +#endif
Why should default depend on DEFERRED_STRUCT_PAGE_INIT at all. This is
just confusing and I do not see how it serves a purpose. We might grow
more optimizations which would prefent early page_ext init.
Let's just have default false and only enforce with the parameter. This
is more predictable and easier to understand.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-08-25 7:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-25 6:31 lizhe.67
2022-08-25 7:11 ` Michal Hocko [this message]
2022-08-25 9:31 ` [PATCH v3] page_ext: introduce boot parameter early_page_ext lizhe.67
2022-08-25 9:36 ` [PATCH v3] page_ext: introduce boot parameter 'early_page_ext' Vlastimil Babka
2022-08-25 10:17 ` lizhe.67
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=YwcgoZfw4RhZ1Bl6@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=Jason@zx2c4.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan.x@bytedance.com \
--cc=lizhe.67@bytedance.com \
--cc=mark-pk.tsai@mediatek.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=vbabka@suse.cz \
--cc=yuanzhu@bytedance.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