On Wed, Nov 22, 2023 at 03:34:13PM +0300, Kirill A. Shutemov wrote:
> On Tue, Nov 21, 2023 at 09:46:57AM -0800, Linus Torvalds wrote:
> > On Tue, 21 Nov 2023 at 04:27, Kirill A. Shutemov
> > <kirill.shutemov@xxxxxxxxxxxxxxx> wrote:
> > >
> > > NR_PAGE_ORDERS defines the number of page orders supported by the page
> > > allocator, ranging from 0 to MAX_ORDER, MAX_ORDER + 1 in total.
> > >
> > > NR_PAGE_ORDERS assists in defining arrays of page orders and allows for
> > > more natural iteration over them.
> >
> > These two patches look much better to me, but I think you missed one area.
> >
> > Most of the Kconfig changes by commit 23baf831a32c ("mm, treewide:
> > redefine MAX_ORDER sanely") should also be basically reverted to use
> > this new NR_PAGE_ORDERS.
>
> I am not convinced.
>
> Some architectures make this option user-visible and, in my view, user
> cares more about the largest page size buddy allocator can provide than
> size of the array inside the allocator.
>
> > IOW, I think the ARCH_FORCE_MAX_ORDER #defines etc should also be done
> > in "number of page orders". I suspect from a documentation standpoint
> > that also makes more sense in places, eg I think that right now your
> > patch says
> >
> > amount of memory for normal system use. The maximum
> > - possible value is MAX_ORDER/2. Setting this parameter
> > + possible value is MAX_PAGE_ORDER/2. Setting this
> >
> > and that's actually nonsensical, because it's NR_PAGE_ORDERS that was
> > at least historically the boundary (and historically the one that was
> > an even number that can be halved cleanly).
>
> Maybe historically (I didn't check), but not now. It is all over the
> place. And it more even in MAX_PAGE_ORDER terms than in NR_PAGE_ORDERS:
>
> ...
Ping?
--
Kiryl Shutsemau / Kirill A. Shutemov
