Received-SPF: pass (google.com: domain of linux-kernel+bounces-48741-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20231221065943.2803551-1-shy828301@gmail.com> <20231221065943.2803551-2-shy828301@gmail.com>
 <878r46ym4b.fsf@oldenburg.str.redhat.com> <CAHbLzkq1ah6y-dCgA0rFePNn3FsE8ebuSNd+jaS8sO51a=X9Yw@mail.gmail.com>
 <87frycryfq.fsf@oldenburg.str.redhat.com>
In-Reply-To: <87frycryfq.fsf@oldenburg.str.redhat.com>
From: Yang Shi <shy828301@gmail.com>
Date: Thu, 1 Feb 2024 11:00:19 -0800
Message-ID: <CAHbLzkqY1=nh0NqpLV+Az+rvT5oE=NhYZT=hOevZhs12T1V=dA@mail.gmail.com>
Subject: Re: [PATCH 2/2] mm: mmap: map MAP_STACK to VM_NOHUGEPAGE
To: Florian Weimer <fweimer@redhat.com>
Cc: oliver.sang@intel.com, riel@surriel.com, fengwei.yin@intel.com, 
	willy@infradead.org, cl@linux.com, ying.huang@intel.com, 
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 1, 2024 at 7:34=E2=80=AFAM Florian Weimer <fweimer@redhat.com> =
wrote:
>
> * Yang Shi:
>
> > On Tue, Jan 30, 2024 at 11:53=E2=80=AFPM Florian Weimer <fweimer@redhat=
com> wrote:
> >>
> >> * Yang Shi:
> >>
> >> > From: Yang Shi <yang@os.amperecomputing.com>
> >> >
> >> > The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> >> > boundaries") incured regression for stress-ng pthread benchmark [1].
> >> > It is because THP get allocated to pthread's stack area much more po=
ssible
> >> > than before.  Pthread's stack area is allocated by mmap without VM_G=
ROWSDOWN
> >> > or VM_GROWSUP flag, so kernel can't tell whether it is a stack area =
or not.
> >> >
> >> > The MAP_STACK flag is used to mark the stack area, but it is a no-op=
 on
> >> > Linux.  Mapping MAP_STACK to VM_NOHUGEPAGE to prevent from allocatin=
g
> >> > THP for such stack area.
> >>
> >> Doesn't this introduce a regression in the other direction, where
> >> workloads expect to use a hugepage TLB entry for the stack?
> >
> > Maybe, it is theoretically possible. But AFAICT, the real life
> > workloads performance usually gets hurt if THP is used for stack.
> > Willy has an example:
> >
> > https://lore.kernel.org/linux-mm/ZYPDwCcAjX+r+g6s@casper.infradead.org/=
#t
> >
> > And avoiding THP on stack is not new, VM_GROWSDOWN | VM_GROWSUP areas
> > have been applied before, this patch just extends this to MAP_STACK.
>
> If it's *always* beneficial then we should help it along in glibc as
> well.  We've started to offer a tunable in response to this observation
> (also paper over in OpenJDK):
>
>   Make thread stacks not use huge pages
>   <https://bugs.openjdk.org/browse/JDK-8303215>
>
> But this is specifically about RSS usage, and not directly about
> reducing TLB misses etc.

Thanks for the data point. Out of curiosity, what mmap flags are used
by JVM to indicate a stack? MAP_STACK? If so it should get
VM_NOHUGEPAGE due to this patch (of course, on older kernel
MADV_NOHUGEPAGE must be called by JVM).

Letting others, for example, glibc, call MADV_NOHUGEPAGE explicitly on
stack area is fine too, but it may take some time to get there...

>
> Thanks,
> Florian
>