From: Michal Hocko <mhocko@suse.com>
To: lizhe.67@bytedance.com
Cc: Jason@zx2c4.com, akpm@linux-foundation.org,
keescook@chromium.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, lizefan.x@bytedance.com,
mark-pk.tsai@mediatek.com, mhiramat@kernel.org,
rostedt@goodmis.org, vbabka@suse.cz, yuanzhu@bytedance.com
Subject: Re: [PATCH] page_ext: move up page_ext_init() to catch early page allocation if DEFERRED_STRUCT_PAGE_INIT is n
Date: Mon, 22 Aug 2022 09:08:42 +0200 [thread overview]
Message-ID: <YwMresZeGmEA6qZP@dhcp22.suse.cz> (raw)
In-Reply-To: <20220820010257.11488-1-lizhe.67@bytedance.com>
On Sat 20-08-22 09:02:57, lizhe.67@bytedance.com wrote:
> On 2022-08-18 7:36 UTC, mhocko@suse.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 move up page_ext_init() to catch early page allocations when
> >> DEFERRED_STRUCT_PAGE_INIT is n. After this patch, we only need to turn
> >> DEFERRED_STRUCT_PAGE_INIT to n then we are able to analyze the early page
> >> allocations. This is useful especially when we find that the free memory
> >> value is not the same right after different kernel booting.
> >
> >is this actually useful in practice? I mean who is going to disable
> >DEFERRED_STRUCT_PAGE_INIT and recompile the kernel for debugging early
> >allocations?
>
> Yes it is useful. We use this method to catch the difference of early
> page allocations between two kernel.
I was not questioning the functionality itself but the way how it is
achieved. Recompiling the kernel to achieve debuggability has proven to
be really a bad approach historically. Most people are using
pre-compiled kernels these days.
> > I do see how debugging those early allocations might be useful but that
> > would require a boot time option to be practical IMHO. Would it make
> > sense to add a early_page_ext parameter which would essentially disable
> > the deferred ipage initialization. That should be quite trivial to
> > achieve (just hook into defer_init AFAICS).
>
> It is a good idea. A cmdline parameter is a flexible and dynamic method for
> us to decide whether to defer page's and page_ext's initilization. For
> comparison, this patch provides a static method to decide whether to defer
> page's and page_ext's initilization. They are not conflicting. My next
> work is trying to achieve your idea.
They are not conflicting but this patch adds ifdefs and additional code
that needs compile time testing with different options set. I.e. it adds
maintenance burden for something that can be achieved by better means.
So if you are ok to work on the runtime knob then I would propose to
drop this patch from the mm tree and replace it by a trivial patch to
allow early boot debugging by a cmd line parameter.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-08-22 7:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 12:09 lizhe.67
2022-08-18 7:36 ` Michal Hocko
2022-08-20 1:02 ` lizhe.67
2022-08-22 7:00 ` Vlastimil Babka
2022-08-24 3:12 ` [PATCH] page_ext: move up page_ext_init() to catch early page allocation if DEFERRED_STRUCT_PAGE_INIT is n' lizhe.67
2022-08-22 7:08 ` Michal Hocko [this message]
2022-08-24 3:17 ` [PATCH] page_ext: move up page_ext_init() to catch early page allocation if DEFERRED_STRUCT_PAGE_INIT is n 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=YwMresZeGmEA6qZP@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=Jason@zx2c4.com \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.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
all inboxes | Powered by JetHome®