linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: WANG Xuerui <kernel@xen0n.name>
To: Mike Rapoport <rppt@kernel.org>, Huacai Chen <chenhuacai@kernel.org>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
	kernel test robot <lkp@intel.com>,
	loongarch@lists.linux.dev,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	oe-kbuild-all@lists.linux.dev,
	Linux Memory Management List <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [linux-next:master 3778/4413] include/linux/mmzone.h:1749:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE
Date: Wed, 22 Mar 2023 15:54:09 +0800	[thread overview]
Message-ID: <723b2eb6-2f4c-8947-0041-a0ced7657885@xen0n.name> (raw)
In-Reply-To: <ZBqxTw5ooh7D80IT@kernel.org>

On 2023/3/22 15:42, Mike Rapoport wrote:
> On Tue, Mar 21, 2023 at 10:59:36AM +0800, Huacai Chen wrote:
>> Hi, all,
>>
>> On Mon, Mar 20, 2023 at 11:56 PM Kirill A. Shutemov
>> <kirill@shutemov.name> wrote:
>>>
>>> On Mon, Mar 20, 2023 at 04:06:33PM +0800, kernel test robot wrote:
>>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>>> head:   73f2c2a7e1d2b31fdd5faa6dfa151c437a6c0a5a
>>>> commit: af8daebdbc0833b8095767ccef7ddce55e9fdf32 [3778/4413] mm, treewide: redefine MAX_ORDER sanely
>>>> config: loongarch-buildonly-randconfig-r003-20230320 (https://download.01.org/0day-ci/archive/20230320/202303201615.Qfu18nWV-lkp@intel.com/config)
>>>> compiler: loongarch64-linux-gcc (GCC) 12.1.0
>>>> reproduce (this is a W=1 build):
>>>>          wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>>>          chmod +x ~/bin/make.cross
>>>>          # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=af8daebdbc0833b8095767ccef7ddce55e9fdf32
>>>>          git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>>>>          git fetch --no-tags linux-next master
>>>>          git checkout af8daebdbc0833b8095767ccef7ddce55e9fdf32
>>>>          # save the config file
>>>>          mkdir build_dir && cp config build_dir/.config
>>>>          COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=loongarch olddefconfig
>>>>          COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=loongarch prepare
>>>>
>>>> If you fix the issue, kindly add following tag where applicable
>>>> | Reported-by: kernel test robot <lkp@intel.com>
>>>> | Link: https://lore.kernel.org/oe-kbuild-all/202303201615.Qfu18nWV-lkp@intel.com/
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>>     In file included from include/linux/gfp.h:7,
>>>>                      from include/linux/mm.h:7,
>>>>                      from arch/loongarch/kernel/asm-offsets.c:9:
>>>>>> include/linux/mmzone.h:1749:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE
>>>>      1749 | #error Allocator MAX_ORDER exceeds SECTION_SIZE
>>>>           |  ^~~~~
>>>
>>> +Loongarch folks.
>> LoongArch defines SECTION_SIZE_BITS as 29, so I think the upper limit
>> of ARCH_FORCE_MAX_ORDER should not be 63, MIPS is similar.
>   
> The ranges MIPS add LoongArch define for ARCH_FORCE_MAX_ORDER are insane.
> I'm going to drop them and leave ARCH_FORCE_MAX_ORDER an int with sane
> defaults.
> 
> As for this splat, in the .config above ARCH_FORCE_MAX_ORDER=14 and
> PAGE_SIZE=64k, so we end up with MAX_ORDER + PAGE_SHIFT being 30, that's
> larger than SECTION_SIZE.
> 
> AFAIK randconfig does not randomize integers, so it's unclear to me how
> ARCH_FORCE_MAX_ORDER got to 14.
> 

As far as I can see, arch/loongarch/Kconfig has the following lines:

 > config ARCH_FORCE_MAX_ORDER
 >         int "Maximum zone order"
 >         range 14 64 if PAGE_SIZE_64KB
 >         default "14" if PAGE_SIZE_64KB
 >         range 12 64 if PAGE_SIZE_16KB
 >         default "12" if PAGE_SIZE_16KB
 >         range 11 64
 >         default "11"

So the value 14 is because PAGE_SIZE_64KB is being set, which I 
confirmed to be the case with this particular run. And I believe the 
stanza is inherited from arch/mips.

Looking at other arches it seems a much smaller upper limit would be 
desirable. Even the lower limit of 14 could be lowered, e.g. 
arch/powerpc has "range 8 9 if PPC64 && PPC_64K_PAGES". Is that okay?

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/



  reply	other threads:[~2023-03-22  7:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20  8:06 [linux-next:master 3778/4413] include/linux/mmzone.h:1749:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE kernel test robot
2023-03-20 15:56 ` Kirill A. Shutemov
2023-03-21  2:59   ` Huacai Chen
2023-03-22  7:42     ` Mike Rapoport
2023-03-22  7:54       ` WANG Xuerui [this message]
2023-03-22  8:11         ` Mike Rapoport
2023-03-22 10:01           ` Kirill A. Shutemov
2023-03-23  7:24             ` Liu, Yujie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=723b2eb6-2f4c-8947-0041-a0ced7657885@xen0n.name \
    --to=kernel@xen0n.name \
    --cc=akpm@linux-foundation.org \
    --cc=chenhuacai@kernel.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=loongarch@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=rppt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).