From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) by kanga.kvack.org (Postfix) with ESMTP id 165556B0585 for ; Wed, 7 Nov 2018 22:08:53 -0500 (EST) Received: by mail-io1-f71.google.com with SMTP id r14-v6so21499030ioc.7 for ; Wed, 07 Nov 2018 19:08:53 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id u19-v6sor1301708ioc.24.2018.11.07.19.08.52 for (Google Transport Security); Wed, 07 Nov 2018 19:08:52 -0800 (PST) MIME-Version: 1.0 References: <20181107100247.13359-1-rainccrun@gmail.com> <20181107102549.GB27423@dhcp22.suse.cz> <20181107135421.GA5638@rapoport-lnx> <20181107141306.GF27423@dhcp22.suse.cz> <20181107143703.GB5638@rapoport-lnx> <20181107150312.GH27423@dhcp22.suse.cz> In-Reply-To: <20181107150312.GH27423@dhcp22.suse.cz> From: cc Date: Thu, 8 Nov 2018 11:08:39 +0800 Message-ID: Subject: Re: [PATCH] mm: Fix a typo in __next_mem_pfn_range() comments. Content-Type: multipart/alternative; boundary="000000000000e7785f057a1e8df6" Sender: owner-linux-mm@kvack.org List-ID: To: mhocko@suse.com Cc: rppt@linux.ibm.com, akpm@linux-foundation.org, rppt@linux.vnet.ibm.com, pasha.tatashin@oracle.com, Jonathan Corbet , stefan@agner.ch, malat@debian.org, neelx@redhat.com, andriy.shevchenko@linux.intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org --000000000000e7785f057a1e8df6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for all your replies=EF=BC=8Ci am a newbie here. Michal Hocko =E4=BA=8E2018=E5=B9=B411=E6=9C=887=E6=97=A5= =E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=8811:03=E5=86=99=E9=81=93=EF=BC=9A > On Wed 07-11-18 16:37:05, Mike Rapoport wrote: > > On Wed, Nov 07, 2018 at 03:13:06PM +0100, Michal Hocko wrote: > > > On Wed 07-11-18 15:54:22, Mike Rapoport wrote: > > > > On Wed, Nov 07, 2018 at 11:25:49AM +0100, Michal Hocko wrote: > > > > > On Wed 07-11-18 18:02:47, Chen Chang wrote: > > > > > > mm: Fix a typo in __next_mem_pfn_range() comments. > > > > > > > > > > those two names are just too similar. And I wouldn't be surprised > if > > > > > there was a considerable overlap in functionality which just asks > for > > > > > a unification. In a separate patch of course. > > > > > > > > There is an overlap, but I'm not sure if the unification is straigh= t > > > > forward. The for_each_mem_pfn_range() is really simple iterator, > while > > > > for_each_mem_range() has additional logic based on memblock flags. > > > > > > Is there any reason we cannot emulate the former by later by type_b = =3D > > > NULL and flags=3D0? > > > > Mostly. There's a hotplug related check: > > > > /* skip hotpluggable memory regions if needed */ > > if (movable_node_is_enabled() && memblock_is_hotpluggable(m)) > > continue; > > > > in __next_mem_range() that is not related to flags and type_b and I don= 't > > understand hotplug enough to tell. > > > > Maybe this check can become > > > > /* skip hotpluggable memory regions if needed */ > > if ((flags & MEMBLOCK_HOTPLUG) && movable_node_is_enabled() && > > memblock_is_hotpluggable(m)) > > continue; > > > > and then using flags=3D0 and type_b=3DNULL would be possible. > > OK, let's discuss this in a separate thread. A simlification in this > area is always welcome ;) > > -- > Michal Hocko > SUSE Labs > --000000000000e7785f057a1e8df6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for all your replies=EF=BC=8Ci am = a newbie here.

M= ichal Hocko <mhocko@suse.com> = =E4=BA=8E2018=E5=B9=B411=E6=9C=887=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5= =8D=8811:03=E5=86=99=E9=81=93=EF=BC=9A
On Wed 07-11-18 16:37:05, Mike Rapoport wrote:
> On Wed, Nov 07, 2018 at 03:13:06PM +0100, Michal Hocko wrote:
> > On Wed 07-11-18 15:54:22, Mike Rapoport wrote:
> > > On Wed, Nov 07, 2018 at 11:25:49AM +0100, Michal Hocko wrote= :
> > > > On Wed 07-11-18 18:02:47, Chen Chang wrote:
> > > > > mm: Fix a typo in __next_mem_pfn_range() comments.=
> > > >
> > > > those two names are just too similar. And I wouldn'= t be surprised if
> > > > there was a considerable overlap in functionality which= just asks for
> > > > a unification. In a separate patch of course.
> > >
> > > There is an overlap, but I'm not sure if the unification= is straight
> > > forward. The for_each_mem_pfn_range() is really simple itera= tor, while
> > > for_each_mem_range() has additional logic based on memblock = flags.
> >
> > Is there any reason we cannot emulate the former by later by type= _b =3D
> > NULL and flags=3D0?
>
> Mostly. There's a hotplug related check:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/* skip hotpluggable memory regions if neede= d */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (movable_node_is_enabled() && mem= block_is_hotpluggable(m))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0continue;
>
> in __next_mem_range() that is not related to flags and type_b and I do= n't
> understand hotplug enough to tell.
>
> Maybe this check can become
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/* skip hotpluggable memory regions if neede= d */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((flags & MEMBLOCK_HOTPLUG) &a= mp;& movable_node_is_enabled() &&
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 memblock_is_hotpluggable(m))<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0continue;=
>
> and then using flags=3D0 and type_b=3DNULL would be possible.

OK, let's discuss this in a separate thread. A simlification in this area is always welcome ;)

--
Michal Hocko
SUSE Labs
--000000000000e7785f057a1e8df6--