All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Yang Shi <shy828301@gmail.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
Subject: Re: [PATCH 2/2] mm: mmap: map MAP_STACK to VM_NOHUGEPAGE
Date: Wed, 31 Jan 2024 08:53:40 +0100	[thread overview]
Message-ID: <878r46ym4b.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20231221065943.2803551-2-shy828301@gmail.com> (Yang Shi's message of "Wed, 20 Dec 2023 22:59:43 -0800")

* 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 possible
> than before.  Pthread's stack area is allocated by mmap without VM_GROWSDOWN
> 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 allocating
> 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?

It's seems an odd approach to fixing the stress-ng regression.  Isn't it
very much coding to the benchmark?

Thanks,
Florian



  parent reply	other threads:[~2024-01-31  7:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-21  6:59 [PATCH 1/2] mm: mmap: no need to call khugepaged_enter_vma() for stack Yang Shi
2023-12-21  6:59 ` [PATCH 2/2] mm: mmap: map MAP_STACK to VM_NOHUGEPAGE Yang Shi
2024-01-10  1:36   ` Yin Fengwei
2024-01-16 19:22     ` Zach O'Keefe
2024-01-16 20:57       ` Yang Shi
2024-01-16 21:31         ` Andrew Morton
2024-01-31  7:53   ` Florian Weimer [this message]
2024-01-31 18:46     ` Yang Shi
2024-02-01 15:34       ` Florian Weimer
2024-02-01 19:00         ` Yang Shi
2024-01-10  1:35 ` [PATCH 1/2] mm: mmap: no need to call khugepaged_enter_vma() for stack Yin Fengwei
2024-01-15  5:50 ` Huang, Ying
2024-01-16 21:39   ` Yang Shi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878r46ym4b.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=fengwei.yin@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oliver.sang@intel.com \
    --cc=riel@surriel.com \
    --cc=shy828301@gmail.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.