Received-SPF: pass (google.com: domain of linux-kernel+bounces-105438-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240311164638.2015063-1-pasha.tatashin@soleen.com>
 <20240311164638.2015063-9-pasha.tatashin@soleen.com> <5b98c4a1-26c0-4b69-b000-44ae97eb6edb@wanadoo.fr>
In-Reply-To: <5b98c4a1-26c0-4b69-b000-44ae97eb6edb@wanadoo.fr>
From: Pasha Tatashin <pasha.tatashin@soleen.com>
Date: Sun, 17 Mar 2024 11:15:30 -0400
Message-ID: <CA+CK2bB+NVzFW5DpmrL3jJPZFyaKyHdqge3KNf1eLBe0YeHhfA@mail.gmail.com>
Subject: Re: [RFC 08/14] fork: separate vmap stack alloction and free calls
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, 
	akpm@linux-foundation.org, x86@kernel.org, bp@alien8.de, brauner@kernel.org, 
	bristot@redhat.com, bsegall@google.com, dave.hansen@linux.intel.com, 
	dianders@chromium.org, dietmar.eggemann@arm.com, eric.devolder@oracle.com, 
	hca@linux.ibm.com, hch@infradead.org, hpa@zytor.com, 
	jacob.jun.pan@linux.intel.com, jgg@ziepe.ca, jpoimboe@kernel.org, 
	jroedel@suse.de, juri.lelli@redhat.com, kent.overstreet@linux.dev, 
	kinseyho@google.com, kirill.shutemov@linux.intel.com, lstoakes@gmail.com, 
	luto@kernel.org, mgorman@suse.de, mic@digikod.net, 
	michael.christie@oracle.com, mingo@redhat.com, mjguzik@gmail.com, 
	mst@redhat.com, npiggin@gmail.com, peterz@infradead.org, pmladek@suse.com, 
	rick.p.edgecombe@intel.com, rostedt@goodmis.org, surenb@google.com, 
	tglx@linutronix.de, urezki@gmail.com, vincent.guittot@linaro.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 17, 2024 at 10:52=E2=80=AFAM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> Le 11/03/2024 =C3=A0 17:46, Pasha Tatashin a =C3=A9crit :
> > In preparation for the dynamic stacks, separate out the
> > __vmalloc_node_range and vfree calls from the vmap based stack
> > allocations. The dynamic stacks will use their own variants of these
> > functions.
> >
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> > ---
> >   kernel/fork.c | 53 ++++++++++++++++++++++++++++++--------------------=
-
> >   1 file changed, 31 insertions(+), 22 deletions(-)
> >
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index 3004e6ce6c65..bbae5f705773 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -204,6 +204,29 @@ static bool try_release_thread_stack_to_cache(stru=
ct vm_struct *vm_area)
> >       return false;
> >   }
> >
> > +static inline struct vm_struct *alloc_vmap_stack(int node)
> > +{
> > +     void *stack;
> > +
> > +     /*
> > +      * Allocated stacks are cached and later reused by new threads,
> > +      * so memcg accounting is performed manually on assigning/releasi=
ng
> > +      * stacks to tasks. Drop __GFP_ACCOUNT.
> > +      */
> > +     stack =3D __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN,
> > +                                  VMALLOC_START, VMALLOC_END,
> > +                                  THREADINFO_GFP & ~__GFP_ACCOUNT,
> > +                                  PAGE_KERNEL,
> > +                                  0, node, __builtin_return_address(0)=
);
> > +
> > +     return (stack) ? find_vm_area(stack) : NULL;
>
> Nit: superfluous ()

Thank you.

>
> > +}
>
> ...
>