On Wed, Dec 20, 2023 at 8:49 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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.
