Messages in this thread | | | Date | Mon, 3 Dec 2018 14:28:49 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP |
| |
On Mon, Dec 03, 2018 at 11:23:58AM +0100, Laszlo Ersek wrote: > Totally uninformed side-question: > > how large can the return value of compound_order() be? MAX_ORDER? > > Apparently, MAX_ORDER can be defined as CONFIG_FORCE_MAX_ZONEORDER. > > "config FORCE_MAX_ZONEORDER" is listed in a number of Kconfig files. > Among those, "arch/mips/Kconfig" permits "ranges" (?) that extend up to > 64. Same applies to "arch/powerpc/Kconfig" and "arch/sh/mm/Kconfig". > > If we left-shift "1" -- a signed int, which I assume in practice will > always have two's complement representation, 1 sign bit, 31 value bits, > and 0 padding bits --, by 31 or more bit positions, we get undefined > behavior (as part of the left-shift operation). > > Is this a practical concern?
Not really.
Assuming 4k PAGE_SIZE, compound_order() == 31 means 8 TiB pages. I doubt we will see such allocation requests any time soon.
Even with 1k base page size, it's still 2 TiB.
We will see other limitations in page allocaiton path before the compund order type will be an issue.
-- Kirill A. Shutemov
| |