Re: [linux-next:master] [mm] 1111d46b5c: stress-ng.pthread.ops_per_sec -84.3% regression

Yang Shi
2023-12-21T18:07:26Z

On Wed, Dec 20, 2023 at 8:49 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Dec 21, 2023 at 08:58:42AM +0800, Yin Fengwei wrote:
> > Yes. MAP_STACK is also mentioned in manpage of mmap. I did test to
> > filter out of the MAP_STACK mapping based on this patch. The regression
> > in stress-ng.pthread was gone. I suppose this is kind of safe because
> > the madvise call is only applied to glibc allocated stack.
> >
> >
> > But what I am not sure was whether it's worthy to do such kind of change
> > as the regression only is seen obviously in micro-benchmark. No evidence
> > showed the other regressionsin this report is related with madvise. At
> > least from the perf statstics. Need to check more on stream/ramspeed.
>
> FWIW, we had a customer report a significant performance problem when
> inadvertently using 2MB pages for stacks. They were able to avoid it by
> using 2044KiB sized stacks ...

Thanks for the report. This provided more justification regarding
honoring MAP_STACK on Linux. Some applications, for example, pthread,
just allocate a fixed size area for stack. This confuses kernel
because kernel tell stack by VM_GROWSDOWN | VM_GROWSUP.

But I'm still a little confused by why THP for stack could result in
significant performance problems. Unless the applications resize the
stack quite often.