[LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks

[LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks

[Pasha Tatashin]

For a long time, an 8K kernel stack was large enough. However, since
2014, the default stack size has increased to 16K [1]. To conserve
memory at Google, we maintained 8K stacks via a custom patch while
verifying that our workload could fit within this limit.

As we qualify new workloads and kernels, we find it more difficult to
keep the stacks at 8K. Therefore, we will increase the stack size to
the mainline value of 16K. However, this translates to a significant
increase in memory usage, potentially counted in petabytes.

With virtually mapped stacks [2], it's possible to implement
auto-growth on faults. Ideally, the vast majority of kernel threads
could fit into 4K or 8K stacks, with only a small number requiring
deeper stacks that would expand as needed.

The complication is that new pages must always be available from
within an interrupt context. To ensure this, pages must be accessible
to kernel threads in an atomic and lockless manner. This could be
achieved by using a per-CPU supply of pages dedicated to handling
kernel-stack faults.

[1] https://lwn.net/Articles/600644
[2] https://lwn.net/Articles/692608

Re: [LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks

[Peter Collingbourne]

On Thu, Feb 22, 2024, 17:04 Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
>
> For a long time, an 8K kernel stack was large enough. However, since
> 2014, the default stack size has increased to 16K [1]. To conserve
> memory at Google, we maintained 8K stacks via a custom patch while
> verifying that our workload could fit within this limit.
>
> As we qualify new workloads and kernels, we find it more difficult to
> keep the stacks at 8K. Therefore, we will increase the stack size to
> the mainline value of 16K. However, this translates to a significant
> increase in memory usage, potentially counted in petabytes.
>
> With virtually mapped stacks [2], it's possible to implement
> auto-growth on faults. Ideally, the vast majority of kernel threads
> could fit into 4K or 8K stacks, with only a small number requiring
> deeper stacks that would expand as needed.
>
> The complication is that new pages must always be available from
> within an interrupt context. To ensure this, pages must be accessible
> to kernel threads in an atomic and lockless manner. This could be
> achieved by using a per-CPU supply of pages dedicated to handling
> kernel-stack faults.
>
> [1] https://lwn.net/Articles/600644
> [2] https://lwn.net/Articles/692608

Hi Pasha,

I wonder if this is another potential use case for bringing back
cleancache, as proposed in [1]? The idea would be that all kernel
stacks have 16KB allocations but only one page accessible and the rest
available as cleancache. We can handle a fault on one of those pages
by discarding the cleancache page and remapping it as r/w.

Peter

[1] https://lore.kernel.org/all/ZdSMbjGf2Fj98diT@raptor/

Re: [LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks

[Matthew Wilcox]

On Fri, Feb 23, 2024 at 01:49:08PM -0800, Peter Collingbourne wrote:
> I wonder if this is another potential use case for bringing back
> cleancache, as proposed in [1]? The idea would be that all kernel
> stacks have 16KB allocations but only one page accessible and the rest
> available as cleancache. We can handle a fault on one of those pages
> by discarding the cleancache page and remapping it as r/w.

That seems like the most complicated way to solve the problem.
Stack pages which have not been accessed contain no data, so do not
need swap or cleancache, they just need to be allocatable.  And the
fault handler needs to be able to handle faults from interrupt context,
which I'm not sure all architectures can do.

The "We need to be able to allocate memory from interrupt context" is
really not that hard to handle; just keep three pages in a per-cpu array.
Refill the array at return-to-process-context.

Re: [LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks

[Peter Collingbourne]

On Fri, Feb 23, 2024 at 1:56 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Feb 23, 2024 at 01:49:08PM -0800, Peter Collingbourne wrote:
> > I wonder if this is another potential use case for bringing back
> > cleancache, as proposed in [1]? The idea would be that all kernel
> > stacks have 16KB allocations but only one page accessible and the rest
> > available as cleancache. We can handle a fault on one of those pages
> > by discarding the cleancache page and remapping it as r/w.
>
> That seems like the most complicated way to solve the problem.
> Stack pages which have not been accessed contain no data, so do not
> need swap or cleancache, they just need to be allocatable.  And the
> fault handler needs to be able to handle faults from interrupt context,
> which I'm not sure all architectures can do.
>
> The "We need to be able to allocate memory from interrupt context" is
> really not that hard to handle; just keep three pages in a per-cpu array.
> Refill the array at return-to-process-context.

Okay, if it doesn't really need that many pages allocated upfront,
that seems like the best approach to me as well.

Peter

Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks

[Michal Hocko]

Hi Pasha,
is this something you still do consider interesting (and also productive
in absence of x86 maintainers) to discuss at LSFMM?

On Thu 22-02-24 20:03:37, Pavel Tatashin wrote:
> For a long time, an 8K kernel stack was large enough. However, since
> 2014, the default stack size has increased to 16K [1]. To conserve
> memory at Google, we maintained 8K stacks via a custom patch while
> verifying that our workload could fit within this limit.
> 
> As we qualify new workloads and kernels, we find it more difficult to
> keep the stacks at 8K. Therefore, we will increase the stack size to
> the mainline value of 16K. However, this translates to a significant
> increase in memory usage, potentially counted in petabytes.
> 
> With virtually mapped stacks [2], it's possible to implement
> auto-growth on faults. Ideally, the vast majority of kernel threads
> could fit into 4K or 8K stacks, with only a small number requiring
> deeper stacks that would expand as needed.
> 
> The complication is that new pages must always be available from
> within an interrupt context. To ensure this, pages must be accessible
> to kernel threads in an atomic and lockless manner. This could be
> achieved by using a per-CPU supply of pages dedicated to handling
> kernel-stack faults.
> 
> [1] https://lwn.net/Articles/600644
> [2] https://lwn.net/Articles/692608
> _______________________________________________
> Lsf-pc mailing list
> Lsf-pc@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc

-- 
Michal Hocko
SUSE Labs

Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks

[Pasha Tatashin]

Hi Michal,

On Tue, Apr 30, 2024 at 9:07 AM Michal Hocko <mhocko@suse.com> wrote:
>
> Hi Pasha,
> is this something you still do consider interesting (and also productive
> in absence of x86 maintainers) to discuss at LSFMM?

Yes, I am going to go over a few alternatives solutions that were both
discussed in RFCv1 thread, and also a new proposal that I've been
working on.

X86 maintainers are not required, as the framework proposals are going
to be arch independent.

Pasha

Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Dynamic Growth of Kernel Stacks

[Michal Hocko]

On Tue 30-04-24 20:20:20, Pavel Tatashin wrote:
> Hi Michal,
> 
> On Tue, Apr 30, 2024 at 9:07 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > Hi Pasha,
> > is this something you still do consider interesting (and also productive
> > in absence of x86 maintainers) to discuss at LSFMM?
> 
> Yes, I am going to go over a few alternatives solutions that were both
> discussed in RFCv1 thread, and also a new proposal that I've been
> working on.
> 
> X86 maintainers are not required, as the framework proposals are going
> to be arch independent.

OK, thanks!
-- 
Michal Hocko
SUSE Labs