[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871qlhv530.fsf@mpe.ellerman.id.au>
Date: Wed, 22 Mar 2023 14:26:59 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...e.de>, Vlastimil Babka <vbabka@...e.cz>,
David Hildenbrand <david@...hat.com>
Cc: linux-mm@...ck.org, linux-arch@...r.kernel.org,
linux-kernel@...r.kernel.org,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH 10/10] mm, treewide: Redefine MAX_ORDER sanely
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com> writes:
> MAX_ORDER currently defined as number of orders page allocator supports:
> user can ask buddy allocator for page order between 0 and MAX_ORDER-1.
>
> This definition is counter-intuitive and lead to number of bugs all over
> the kernel.
>
> Change the definition of MAX_ORDER to be inclusive: the range of orders
> user can ask from buddy allocator is 0..MAX_ORDER now.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> ---
...
> arch/powerpc/Kconfig | 27 ++++++-------
> arch/powerpc/configs/85xx/ge_imp3a_defconfig | 2 +-
> arch/powerpc/configs/fsl-emb-nonhw.config | 2 +-
> arch/powerpc/mm/book3s64/iommu_api.c | 2 +-
> arch/powerpc/mm/hugetlbpage.c | 2 +-
> arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
Reviewed-by: Michael Ellerman <mpe@...erman.id.au> (powerpc)
cheers
Powered by blists - more mailing lists