[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230406154423.20a991bbdd47630fc38d94e8@linux-foundation.org>
Date: Thu, 6 Apr 2023 15:44:23 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Mike Rapoport <rppt@...nel.org>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>,
Guenter Roeck <linux@...ck-us.net>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm-treewide-redefine-max_order-sanely-fix.txt
On Fri, 7 Apr 2023 00:14:31 +0300 Mike Rapoport <rppt@...nel.org> wrote:
> > > Shouldn't that be
> > > else
> > > order = 0;
> > > ?
> >
> > +Mike.
> >
> > No. start == 0 is MAX_ORDER-aligned. We want to free the pages in the
> > largest chunks alignment allows.
>
> Right. Before the changes to MAX_ORDER it was
>
> order = min(MAX_ORDER - 1UL, __ffs(start));
>
> which would evaluate to 10.
>
> I'd just prefer the comment to include the explanation about why we choose
> MAX_ORDER for start == 0. Say
>
> /*
> * __ffs() behaviour is undefined for 0 and we want to free the
> * pages in the largest chunks alignment allows, so set order to
> * MAX_ORDER when start == 0
> */
Meanwhile I'd like to fix "various boot failures (hang) on arm targets"
in -next, so I queued up Kirill's informal fix for now.
Powered by blists - more mailing lists