On Mon, Jun 6, 2022 at 3:23 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 6 Jun 2022 09:40:20 -0700 "Zach O'Keefe" <zokeefe@xxxxxxxxxx> wrote: > > > On Sun, Jun 5, 2022 at 7:42 PM kernel test robot <lkp@xxxxxxxxx> 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@xxxxxxxxx/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@xxxxxxxxx> > > > > > > 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@xxxxxxxxx. > > > > 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? Thanks, Andrew. Yeah, I just suggested that too. > > I'll await some reviewer input (hopefully positive ;)) before merging > this series.
