Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CGME20220509073953epcas1p127f2d36186316642068c92c5d9dee1c4@epcas1p1.samsung.com>
 <20220509074330.4822-1-jaewon31.kim@samsung.com> <20220516173321.67402b7f09eacc43d4e476f4@linux-foundation.org>
 <YoNcBG6kQnmLZ3Z9@linux.ibm.com> <CAJrd-UuzTh-0Ee9+rMRES9onP_EkvJS-VpPP66J4M4n0Ku0ZWA@mail.gmail.com>
 <YoObTJcBUjeW+2l2@linux.ibm.com> <CAJrd-UtYqEMy+Yr9gP0v0dZ3HZ=fCHe67dTRe=5YtLWrbmd1UQ@mail.gmail.com>
 <YoT1LMALyqTUtg6e@linux.ibm.com>
In-Reply-To: <YoT1LMALyqTUtg6e@linux.ibm.com>
From:   Jaewon Kim <jaewon31.kim@gmail.com>
Date:   Thu, 19 May 2022 09:20:20 +0900
Message-ID: <CAJrd-UuxYyoyWyjd5GTMpCUFrOT_RB=tEPCGTWC71DNC3HDALA@mail.gmail.com>
Subject: Re: [RFC PATCH] page_ext: create page extension for all memblock
 memory regions
To:     Mike Rapoport <rppt@linux.ibm.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Jaewon Kim <jaewon31.kim@samsung.com>,
        Vlastimil Babka <vbabka@suse.cz>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

As I said it is v5.10 based kernel.
 ; Actually I am using v5.10 based source tree on an arm64 device.

Thank you
Jaewon Kim

2022=EB=85=84 5=EC=9B=94 18=EC=9D=BC (=EC=88=98) =EC=98=A4=ED=9B=84 10:31, =
Mike Rapoport <rppt@linux.ibm.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
>
> On Tue, May 17, 2022 at 10:10:20PM +0900, Jaewon Kim wrote:
> > 64
> > 59
> >
> > 2022=EB=85=84 5=EC=9B=94 17=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 9:5=
5, Mike Rapoport <rppt@linux.ibm.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
> > >
> > > 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 'al=
l
> > > > struct pages in any section should be valid and
> > > > properly initialized' ?
> > >
> > > There were several commits that refactored the memory map initializat=
ion,
> > > freeing of the unused memory map and abuse of pfn_valid() as a substi=
tute
> > > 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 kerne=
l.
> > > 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 =3D 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 ent=
ire
> > > section if the first pfn in that section is not memory that can be ma=
pped
> > > 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 devic=
es.
> > The next version on our devices seems to be v5.15 though.
> >
> > Thank you
> > Jaewon Kim
>
> --
> Sincerely yours,
> Mike.