From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: Usama Arif <usamaarif642@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
david@redhat.com, linux-mm@kvack.org, hannes@cmpxchg.org,
shakeel.butt@linux.dev, riel@surriel.com, ziy@nvidia.com,
laoar.shao@gmail.com, baolin.wang@linux.alibaba.com,
lorenzo.stoakes@oracle.com, npache@redhat.com,
ryan.roberts@arm.com, vbabka@suse.cz, jannh@google.com,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH v3 0/7] prctl: introduce PR_SET/GET_THP_POLICY
Date: Tue, 20 May 2025 22:33:27 -0400 [thread overview]
Message-ID: <p3lc5tuzpblwtikfodj5d5wjbpklqwg6oexn4xw3cdwspqwkmy@l7vhj72rjgsb> (raw)
In-Reply-To: <20250519223307.3601786-1-usamaarif642@gmail.com>
* Usama Arif <usamaarif642@gmail.com> [250519 18:34]:
> This series allows to change the THP policy of a process, according to the
> value set in arg2, all of which will be inherited during fork+exec:
> - PR_DEFAULT_MADV_HUGEPAGE: This will set VM_HUGEPAGE and clear VM_NOHUGEPAGE
> for the default VMA flags. It will also iterate through every VMA in the
> process and call hugepage_madvise on it, with MADV_HUGEPAGE policy.
> This effectively allows setting MADV_HUGEPAGE on the entire process.
> In an environment where different types of workloads are run on the
> same machine, this will allow workloads that benefit from always having
> hugepages to do so, without regressing those that don't.
> - PR_DEFAULT_MADV_NOHUGEPAGE: This will set VM_NOHUGEPAGE and clear VM_HUGEPAGE
> for the default VMA flags. It will also iterate through every VMA in the
> process and call hugepage_madvise on it, with MADV_NOHUGEPAGE policy.
> This effectively allows setting MADV_NOHUGEPAGE on the entire process.
> In an environment where different types of workloads are run on the
> same machine,this will allow workloads that benefit from having
> hugepages on an madvise basis only to do so, without regressing those
> that benefit from having hugepages always.
> - PR_THP_POLICY_SYSTEM: This will reset (clear) both VM_HUGEPAGE and
> VM_NOHUGEPAGE process for the default flags.
>
Subject seems outdated now? PR_DEFAULT_ vs PR_SET/GET_THP ?
On that note, doesn't it make sense to change the default mm flag under
PR_SET_MM? PR_SET_MM_FLAG maybe?
Thanks,
Liam
next prev parent reply other threads:[~2025-05-21 2:39 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 22:29 Usama Arif
2025-05-19 22:29 ` [PATCH v3 1/7] mm: khugepaged: extract vm flag setting outside of hugepage_madvise Usama Arif
2025-05-20 9:51 ` kernel test robot
2025-05-20 14:43 ` Lorenzo Stoakes
2025-05-20 14:57 ` Usama Arif
2025-05-20 15:13 ` Usama Arif
2025-05-20 15:31 ` Lorenzo Stoakes
2025-05-19 22:29 ` [PATCH v3 2/7] prctl: introduce PR_DEFAULT_MADV_HUGEPAGE for the process Usama Arif
2025-05-19 23:01 ` Jann Horn
2025-05-20 5:23 ` Lorenzo Stoakes
2025-05-20 9:09 ` David Hildenbrand
2025-05-20 9:16 ` Lorenzo Stoakes
2025-05-20 8:48 ` kernel test robot
2025-05-19 22:29 ` [PATCH v3 3/7] prctl: introduce PR_DEFAULT_MADV_NOHUGEPAGE " Usama Arif
2025-05-19 22:29 ` [PATCH v3 4/7] prctl: introduce PR_THP_POLICY_SYSTEM " Usama Arif
2025-05-19 22:29 ` [PATCH v3 5/7] selftests: prctl: introduce tests for PR_DEFAULT_MADV_NOHUGEPAGE Usama Arif
2025-05-19 22:29 ` [PATCH v3 6/7] selftests: prctl: introduce tests for PR_THP_POLICY_DEFAULT_HUGE Usama Arif
2025-05-19 22:29 ` [PATCH v3 7/7] docs: transhuge: document process level THP controls Usama Arif
2025-05-20 5:14 ` [PATCH v3 0/7] prctl: introduce PR_SET/GET_THP_POLICY Lorenzo Stoakes
2025-05-20 7:46 ` Usama Arif
2025-05-20 8:51 ` Lorenzo Stoakes
2025-05-21 2:33 ` Liam R. Howlett [this message]
2025-05-21 9:31 ` Usama Arif
2025-05-21 16:37 ` Liam R. Howlett
2025-05-22 12:10 ` Mike Rapoport
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=p3lc5tuzpblwtikfodj5d5wjbpklqwg6oexn4xw3cdwspqwkmy@l7vhj72rjgsb \
--to=liam.howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=jannh@google.com \
--cc=kernel-team@meta.com \
--cc=laoar.shao@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=npache@redhat.com \
--cc=riel@surriel.com \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=usamaarif642@gmail.com \
--cc=vbabka@suse.cz \
--cc=ziy@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox