* Re: [PATCH] page_ext: move up page_ext_init() to catch early page allocation if DEFERRED_STRUCT_PAGE_INIT is n [not found] <Yv3r6Y1vh+6AbY4+@dhcp22.suse.cz> @ 2022-08-20 1:02 ` lizhe.67 2022-08-22 7:00 ` Vlastimil Babka 0 siblings, 1 reply; 3+ messages in thread From: lizhe.67 @ 2022-08-20 1:02 UTC (permalink / raw) To: mhocko Cc: Jason, akpm, keescook, linux-kernel, linux-mm, lizefan.x, lizhe.67, mark-pk.tsai, mhiramat, rostedt, vbabka, yuanzhu 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 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. -- Li Zhe ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] page_ext: move up page_ext_init() to catch early page allocation if DEFERRED_STRUCT_PAGE_INIT is n 2022-08-20 1:02 ` [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: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 0 siblings, 1 reply; 3+ messages in thread From: Vlastimil Babka @ 2022-08-22 7:00 UTC (permalink / raw) To: lizhe.67, mhocko Cc: Jason, akpm, keescook, linux-kernel, linux-mm, lizefan.x, mark-pk.tsai, mhiramat, rostedt, yuanzhu On 8/20/22 03:02, 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 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. As we already have to pass page_owner=on parameter to enable the page allocation tracking in the first place, maybe that alone could also disable deffered init, and no need for another parameter? > -- > Li Zhe ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] page_ext: move up page_ext_init() to catch early page allocation if DEFERRED_STRUCT_PAGE_INIT is n' 2022-08-22 7:00 ` Vlastimil Babka @ 2022-08-24 3:12 ` lizhe.67 0 siblings, 0 replies; 3+ messages in thread From: lizhe.67 @ 2022-08-24 3:12 UTC (permalink / raw) To: vbabka Cc: Jason, akpm, keescook, linux-kernel, linux-mm, lizefan.x, lizhe.67, mark-pk.tsai, mhiramat, mhocko, rostedt, yuanzhu On 2022-08-22 7:00 UTC, vbabka@suse.cz 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 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. > >As we already have to pass page_owner=on parameter to enable the page >allocation tracking in the first place, maybe that alone could also disable >deffered init, and no need for another parameter? In my opinion, adding a new parameter is better. Page owner is not the only feature attached to page_ext. For scalability reasons, adding a new parameter is a more flexible method. Thanks for your advice. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-08-24 3:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <Yv3r6Y1vh+6AbY4+@dhcp22.suse.cz>
2022-08-20 1:02 ` [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: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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox