[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <mpbxc7boje4aun4pzfoipz2hwaeq75rg3kl2epdpenq5hhomyn@6uj6brlaujwc>
Date: Wed, 24 Jul 2024 13:49:14 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: 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 v5 2/3] vmstat: Kernel stack usage histogram
On Wed, Jul 24, 2024 at 08:33:21PM GMT, Pasha Tatashin 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.
>
> The histogram data is presented in /proc/vmstat with entries like
> "kstack_1k", "kstack_2k", and so on, indicating the number of threads
> that exited with stack usage falling within each respective bucket.
>
> Example outputs:
> Intel:
> $ grep kstack /proc/vmstat
> kstack_1k 3
> kstack_2k 188
> kstack_4k 11391
> kstack_8k 243
> kstack_16k 0
>
> ARM with 64K page_size:
> $ grep kstack /proc/vmstat
> kstack_1k 1
> kstack_2k 340
> kstack_4k 25212
> kstack_8k 1659
> kstack_16k 0
> kstack_32k 0
> kstack_64k 0
>
> Note: once the dynamic kernel stack is implemented it will depend on the
> implementation the usability of this feature: On hardware that supports
> faults on kernel stacks, we will have other metrics that show the total
> number of pages allocated for stacks. On hardware where faults are not
> supported, we will most likely have some optimization where only some
> threads are extended, and for those, these metrics will still be very
> useful.
>
> [1] https://lwn.net/Articles/974367
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@...een.com>
> Reviewed-by: Kent Overstreet <kent.overstreet@...ux.dev>
Acked-by: Shakeel Butt <shakeel.butt@...ux.dev>
Powered by blists - more mailing lists