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.
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).
So that kernel parameter should be in terms of NR_PAGE_ORDERS.
But yes, I do think the naming now makes more sense, so other than
that reaction I think these changes are good.
Linus
