Re: [PATCH v3] vmstat: Kernel stack usage histogram

[Pasha Tatashin <pasha.tatashin@soleen.com>]

On Wed, Jun 12, 2024 at 2:50 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
>
> Hi Pasha, I think you might have missed the questions I had below. Your
> response would really be appreciated.

Hi Shakeel,

Sorry for the delayed reply. I was distracted by unrelated tasks and
did not make any progress on this project. To answer your questions:

>
> On Fri, May 31, 2024 at 03:42:34PM GMT, Shakeel Butt wrote:
> > On Thu, May 30, 2024 at 08:14:17PM GMT, Pasha Tatashin wrote:
> > > Hi Shakeel,
> > >
> > > > Couple of questions:
> > > >
> > > > 1. In future with your on-demand kstack allocation feature, will these
> > > > metrics still be useful? (I think so but I want to know your take)
> > >
> > > It depends on how on-demand allocation is implemented. On hardware
> > > that supports faults on kernel stacks,
> >
> > Which hardware supports faults on kernel stacks and which do not?

From my understanding, both ARM64 architecture is capable and also
Intel FRED is capable of handling kernel faults within the kernel
itself, other variants of x86-64 are not.

However, my immediate goal is to provide a generic way to increase
kernel thread memory on demand, specifically when needed. If certain
architectures are capable of in-kernel fault handling, they could
potentially leverage my framework to further enhance their dynamic
stack fault handling support.

> >
> > > we will have other metrics that
> > > show the total number of pages allocated for stacks.
> >
> > Don't we already have a metric for that i.e. KernelStack in meminfo
> > which is in kB unit?

If we had true dynamic kernel stack support, then the metric in
meminfo would be enough to estimate the average stack size, it would
still not show the histogram of how large stacks get.

> >
> > One more question: Is there any concern in making
> > CONFIG_DEBUG_STACK_USAGE not a debug feature i.e. enable in default
> > kernels instead of just debug kernels?

We enabled it in Google ProdKernel. There is some overhead when
threads are exiting, because we are looking for the first non-zero
byte, but that is minimal. We haven't observed any performance impact
on our fleet.

Pasha