linux-kernel - Re: [PATCH v4] vmstat: Kernel stack usage histogram

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <xdumlsfpg3v6hoqdco4acpaudsk2edhgtrabhqdon5lc4nekix@hejsxuay75pr>
Date: Wed, 24 Jul 2024 09:59:41 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, jpoimboe@...nel.org, 
	kent.overstreet@...ux.dev, peterz@...radead.org, nphamcs@...il.com, 
	cerasuolodomenico@...il.com, surenb@...gle.com, lizhijian@...itsu.com, willy@...radead.org, 
	vbabka@...e.cz, ziy@...dia.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v4] vmstat: Kernel stack usage histogram

On Wed, Jul 24, 2024 at 10:43:59AM GMT, Pasha Tatashin wrote:
> On Wed, Jul 24, 2024 at 2:46 AM Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> > On Thu, 18 Jul 2024 20:26:11 +0000 Pasha Tatashin <pasha.tatashin@...een.com> wrote:
> >
> > > As part of the dynamic kernel stack project, we need to know the amount
> > > of data that can be saved by reducing the default kernel stack size [1].
> > >
> > > Provide a kernel stack usage histogram to aid in optimizing kernel stack
> > > sizes and minimizing memory waste in large-scale environments. The
> > > histogram divides stack usage into power-of-two buckets and reports the
> > > results in /proc/vmstat. This information is especially valuable in
> > > environments with millions of machines, where even small optimizations
> > > can have a significant impact.
> >
> > x86_64 allmodconfig:
> >
> > In file included from <command-line>:
> > In function 'init_memcg_events',
> >     inlined from 'mem_cgroup_css_alloc' at mm/memcontrol.c:3616:3:
> > ././include/linux/compiler_types.h:510:45: error: call to '__compiletime_assert_2305' declared with attribute error: BUILD_BUG_ON failed: NR_VM_EVENT_ITEMS >= S8_MAX
> >   510 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> >       |                                             ^
> > ././include/linux/compiler_types.h:491:25: note: in definition of macro '__compiletime_assert'
> >   491 |                         prefix ## suffix();                             \
> >       |                         ^~~~~~
> > ././include/linux/compiler_types.h:510:9: note: in expansion of macro '_compiletime_assert'
> >   510 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> >       |         ^~~~~~~~~~~~~~~~~~~
> > ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
> >    39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> >       |                                     ^~~~~~~~~~~~~~~~~~
> > ./include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> >    50 |         BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> >       |         ^~~~~~~~~~~~~~~~
> > mm/memcontrol.c:444:9: note: in expansion of macro 'BUILD_BUG_ON'
> >   444 |         BUILD_BUG_ON(NR_VM_EVENT_ITEMS >= S8_MAX);
> >       |         ^~~~~~~~~~~~
> >
> > This looks legitimate - is it time to switch to int16_t?
> 
> I am looking into this, and will also uninline stack_not_used() and
> kstack_histogram() as discussed earlier in the thread.
> 

Let me take care of this specific build error.