On Mon 20-06-16 16:43:34, Andy Lutomirski wrote:
> Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
> zone. This only makes sense if each kernel stack exists entirely in
> one zone, and allowing vmapped stacks could break this assumption.
>
> Since frv has THREAD_SIZE <
On Mon 20-06-16 16:43:34, Andy Lutomirski wrote:
> Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
> zone. This only makes sense if each kernel stack exists entirely in
> one zone, and allowing vmapped stacks could break this assumption.
>
> Since frv has THREAD_SIZE <
On Mon, Jun 20, 2016 at 04:43:34PM -0700, Andy Lutomirski wrote:
> Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
> zone. This only makes sense if each kernel stack exists entirely in
> one zone, and allowing vmapped stacks could break this assumption.
>
> Since frv has
On Mon, Jun 20, 2016 at 04:43:34PM -0700, Andy Lutomirski wrote:
> Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
> zone. This only makes sense if each kernel stack exists entirely in
> one zone, and allowing vmapped stacks could break this assumption.
>
> Since frv has
Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
zone. This only makes sense if each kernel stack exists entirely in
one zone, and allowing vmapped stacks could break this assumption.
Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack
allocations in a unit
Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
zone. This only makes sense if each kernel stack exists entirely in
one zone, and allowing vmapped stacks could break this assumption.
Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack
allocations in a unit
6 matches
Mail list logo