On 1/3/19 11:59 AM, Michal Hocko wrote: >> As mentioned above, "If deselected DEFERRED_STRUCT_PAGE_INIT, it is still >> better >> to call page_ext_init() earlier, so page owner could catch more early page >> allocation call sites." > > Do you have any numbers to show how many allocation are we losing that > way? In other words, do we care enough to create an ugly code?
Well, I don't have any numbers, but I read that Joonsoo did not really like to defer page_ext_init() unconditionally. "because deferring page_ext_init() would make page owner which uses page_ext miss some early page allocation callsites. Although it already miss some early page allocation callsites, we don't need to miss more." https://lore.kernel.org/lkml/20160524053714.GB32186@js1304-P5Q-DELUXE/ >>>> diff --git a/mm/page_ext.c b/mm/page_ext.c >>>> index ae44f7adbe07..d76fd51e312a 100644 >>>> --- a/mm/page_ext.c >>>> +++ b/mm/page_ext.c >>>> @@ -399,9 +399,8 @@ void __init page_ext_init(void) >>>> * -------------pfn--------------> >>>> * N0 | N1 | N2 | N0 | N1 | N2|.... >>>> * >>>> - * Take into account DEFERRED_STRUCT_PAGE_INIT. >>>> */ >>>> - if (early_pfn_to_nid(pfn) != nid) >>>> + if (pfn_to_nid(pfn) != nid) >>>> continue; >>>> if (init_section_page_ext(pfn, nid)) >>>> goto oom; >>> >>> Also this doesn't seem to be related, right? >> >> No, it is related. Because of this patch, page_ext_init() is called after all >> the memory has already been initialized, >> so no longer necessary to call early_pfn_to_nid(). > > Yes, but it looks like a follow up cleanup/optimization to me. That early_pfn_to_nid() was introduced in fe53ca54270 (mm: use early_pfn_to_nid in page_ext_init) which also messed up the order of page_ext_init() in start_kernel(), so this patch basically revert that commit.
