On Mon, 6 Jun 2022 09:40:20 -0700 "Zach O'Keefe" <zokeefe@google.com> wrote:

> On Sun, Jun 5, 2022 at 7:42 PM kernel test robot <lkp@intel.com> wrote:
> >
> > Hi Zach,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on akpm-mm/mm-everything]
> >
> > url:    https://github.com/intel-lab-lkp/linux/commits/Zach-O-Keefe/mm-userspace-hugepage-collapse/20220606-012953
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> > config: x86_64-rhel-8.3 (https://download.01.org/0day-ci/archive/20220606/202206060911.I8rRqGwC-lkp@intel.com/config)
> > compiler: gcc-11 (Debian 11.3.0-1) 11.3.0
> > reproduce (this is a W=1 build):
> >         # https://github.com/intel-lab-lkp/linux/commit/d87b6065d6050b89930cca0814921aca7c269286
> >         git remote add linux-review https://github.com/intel-lab-lkp/linux
> >         git fetch --no-tags linux-review Zach-O-Keefe/mm-userspace-hugepage-collapse/20220606-012953
> >         git checkout d87b6065d6050b89930cca0814921aca7c269286
> >         # save the config file
> >         mkdir build_dir && cp config build_dir/.config
> >         make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > All warnings (new ones prefixed by >>):
> >
> >    mm/khugepaged.c: In function 'khugepaged':
> > >> mm/khugepaged.c:2284:1: warning: the frame size of 4160 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> >     2284 | }
> >          | ^
> 
> Thanks lkp@intel.com.
> 
> This is due to config with:
> 
> CONFIG_FRAME_WARN=2048
> CONFIG_NODES_SHIFT=10
> 
> Where struct collapse_control has a member int
> node_load[MAX_NUMNODES], and we stack allocate one.
> 
> Is this a configuration that needs to be supported? 1024 nodes seems
> like a lot and I'm not sure if these configs are randomly generated or
> are reminiscent of real systems.

Adding 4k to the stack isn't a good thing to do.  It's trivial to
kmalloc the thing, so why not do that?

I'll await some reviewer input (hopefully positive ;)) before merging
this series.