On Tue, May 17, 2022 at 10:10:20PM +0900, Jaewon Kim wrote: > 64 > 59 > > 2022년 5월 17일 (화) 오후 9:55, Mike Rapoport <rppt@xxxxxxxxxxxxx>님이 작성: > > > > On Tue, May 17, 2022 at 08:38:18PM +0900, Jaewon Kim wrote: > > > Hello Mike Rapoport > > > Thank you for your comment. > > > > > > Oh really? Could you point out the code or the commit regarding 'all > > > struct pages in any section should be valid and > > > properly initialized' ? > > > > There were several commits that refactored the memory map initialization, > > freeing of the unused memory map and abuse of pfn_valid() as a substitute > > of "is memory valid" semantics. > > > > > Actually I am using v5.10 based source tree on an arm64 device. > > > > Then most probably your change is not relevant for the upstream kernel. > > Did you observe any issues with page_ext initialization on v5.18-rcN > > kernels? > > Actually I observed only 59 sections were initialized for page_ext and > missed 5 sections. > It should be totally 64 sections * 128 MB = 8,192 MB Does this happen with v5.10 based kernel or with v5.18-rcN based kernel? > > > I tried to look up and found the following commit in v5.16-rc1, did > > > you mean this? > > > 3de360c3fdb3 arm64/mm: drop HAVE_ARCH_PFN_VALID > > > > Yes, this is one of those commits. > > > > > I guess memblock_is_memory code in pfn_valid in arch/arm64/mm/init.c, v5.10 > > > might affect the page_ext_init. > > > > Yes. In 5.10 the pfn_valid() test in page_ext_init() will skip an entire > > section if the first pfn in that section is not memory that can be mapped > > in the linear map. > > > > But again, this should be fixed in the latest kernels. > > Great! Thank you for your explanation. > I will check it someday later when I use the latest kernel on our devices. > The next version on our devices seems to be v5.15 though. > > Thank you > Jaewon Kim -- Sincerely yours, Mike.
