linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: wang wei <a929244872@163.com>
Cc: akpm@linux-foundation.org, hughd@google.com, willy@infradead.org,
	david@redhat.com, wangkefeng.wang@huawei.com,
	ying.huang@intel.com, 21cnbao@gmail.com, ryan.roberts@arm.com,
	shy828301@gmail.com, ziy@nvidia.com, ioworker0@gmail.com,
	da.gomez@samsung.com, p.raghav@samsung.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/6] mm: shmem: add multi-size THP sysfs interface for anonymous shmem
Date: Sun, 2 Jun 2024 12:36:19 +0800	[thread overview]
Message-ID: <bba3ab3d-6e9c-4c62-9c85-3a3d338d9230@linux.alibaba.com> (raw)
In-Reply-To: <4e918c74.1262.18fd1d870d6.Coremail.a929244872@163.com>



On 2024/6/1 11:29, wang wei wrote:
> At 2024-05-30 10:04:14, "Baolin Wang" <baolin.wang@linux.alibaba.com> wrote:
> 
>>To support the use of mTHP with anonymous shmem, add a new sysfs interface
>>'shmem_enabled' in the '/sys/kernel/mm/transparent_hugepage/hugepages-kB/'
>>directory for each mTHP to control whether shmem is enabled for that mTHP,
>>with a value similar to the top level 'shmem_enabled', which can be set to:
>>"always", "inherit (to inherit the top level setting)", "within_size", "advise",
>>"never", "deny", "force". These values follow the same semantics as the top
>>level, except the 'deny' is equivalent to 'never', and 'force' is equivalent
>>to 'always' to keep compatibility.
>>
>>By default, PMD-sized hugepages have enabled="inherit" and all other hugepage
>>sizes have enabled="never" for '/sys/kernel/mm/transparent_hugepage/hugepages-xxkB/shmem_enabled'.
>>
>>In addition, if top level value is 'force', then only PMD-sized hugepages
>>have enabled="inherit", otherwise configuration will be failed and vice versa.
>>That means now we will avoid using non-PMD sized THP to override the global
>>huge allocation.
>>
>>Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>>---
>> Documentation/admin-guide/mm/transhuge.rst | 29 +++++++
>> include/linux/huge_mm.h                    | 10 +++
>> mm/huge_memory.c                           | 11 +--
>> mm/shmem.c                                 | 96 ++++++++++++++++++++++
>> 4 files changed, 138 insertions(+), 8 deletions(-)
>>
>>diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
>>index d414d3f5592a..659459374032 100644
>>--- a/Documentation/admin-guide/mm/transhuge.rst
>>+++ b/Documentation/admin-guide/mm/transhuge.rst
>>@@ -332,6 +332,35 @@ deny
>> force
>>     Force the huge option on for all - very useful for testing;
>> 
>>+Anonymous shmem can also use "multi-size THP" (mTHP) by adding a new sysfs knob
>>+to control mTHP allocation: /sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/shmem_enabled.
>>+Its value for each mTHP is essentially consistent with the global setting, except
>>+for the addition of 'inherit' to ensure compatibility with the global settings.
>>+always
>>+    Attempt to allocate <size> huge pages every time we need a new page;
>>+
>>+inherit
>>+    Inherit the top-level "shmem_enabled" value. By default, PMD-sized hugepages
>>+    have enabled="inherit" and all other hugepage sizes have enabled="never";
>>+
>>+never
>>+    Do not allocate <size> huge pages;
>>+
>>+within_size
>>+    Only allocate <size> huge page if it will be fully within i_size.
>>+    Also respect fadvise()/madvise() hints;
>>+
>>+advise
>>+    Only allocate <size> huge pages if requested with fadvise()/madvise();
>>+
>>+deny
>>+    Has the same semantics as 'never', now mTHP allocation policy is only
>>+    used for anonymous shmem and no not override tmpfs.
>>+
>>+force
>>+    Has the same semantics as 'always', now mTHP allocation policy is only
>>+    used for anonymous shmem and no not override tmpfs.
>  >+
> 
> I just briefly reviewed the discussion about the value of 
> hugepages-<size>kB/shmem_enabled
> in V1 [PATCH 5/8]. Is there a conclusion now? Maybe I left out some 
> important information.

You can refer to the this patch's commit message and documentation, 
which are based on the conclusions of previous discussions.

In addition, you can also read more discussions from the last bi-weekly 
MM meeting[1], summarized by David.

[1] 
https://lore.kernel.org/all/f1783ff0-65bd-4b2b-8952-52b6822a0835@redhat.com/#t


  reply	other threads:[~2024-06-02  4:36 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-30  2:04 [PATCH v3 0/6] add mTHP support " Baolin Wang
2024-05-30  2:04 ` [PATCH v3 1/6] mm: memory: extend finish_fault() to support large folio Baolin Wang
2024-06-03  4:44   ` Lance Yang
2024-06-03  8:04     ` Baolin Wang
2024-06-03  5:28   ` Barry Song
2024-06-03  8:29     ` Baolin Wang
2024-06-03  8:58       ` Barry Song
2024-06-03  9:01         ` Barry Song
2024-06-03  9:37           ` Baolin Wang
2024-05-30  2:04 ` [PATCH v3 2/6] mm: shmem: add THP validation for PMD-mapped THP related statistics Baolin Wang
2024-05-30  2:04 ` [PATCH v3 3/6] mm: shmem: add multi-size THP sysfs interface for anonymous shmem Baolin Wang
2024-06-01  3:29   ` wang wei
2024-06-02  4:36     ` Baolin Wang [this message]
2024-05-30  2:04 ` [PATCH v3 4/6] mm: shmem: add mTHP support " Baolin Wang
2024-05-30  6:36   ` kernel test robot
2024-06-02  4:16     ` Baolin Wang
2024-06-04  9:23   ` Dan Carpenter
2024-06-04  9:46     ` Baolin Wang
2024-05-30  2:04 ` [PATCH v3 5/6] mm: shmem: add mTHP size alignment in shmem_get_unmapped_area Baolin Wang
2024-05-30  2:04 ` [PATCH v3 6/6] mm: shmem: add mTHP counters for anonymous shmem Baolin Wang
2024-05-31  9:35 ` [PATCH v3 0/6] add mTHP support " David Hildenbrand
2024-05-31 10:13   ` Baolin Wang
2024-05-31 11:13     ` David Hildenbrand
2024-06-02  4:15       ` Baolin Wang
2024-06-04  8:18       ` Daniel Gomez
2024-06-04  9:45         ` Baolin Wang
2024-06-04 12:05           ` Daniel Gomez
2024-06-06  3:31             ` Baolin Wang
2024-06-06  8:38               ` David Hildenbrand
2024-06-06  9:31                 ` Baolin Wang
2024-06-07  9:05                 ` Daniel Gomez
2024-06-07 10:39                   ` David Hildenbrand
2024-06-01  3:54     ` wang wei
2024-05-31 13:19   ` Daniel Gomez
2024-05-31 14:43     ` David Hildenbrand
2024-06-04  9:29       ` Daniel Gomez
2024-06-04  9:59         ` David Hildenbrand
2024-06-04 12:30           ` Daniel Gomez

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=bba3ab3d-6e9c-4c62-9c85-3a3d338d9230@linux.alibaba.com \
    --to=baolin.wang@linux.alibaba.com \
    --cc=21cnbao@gmail.com \
    --cc=a929244872@163.com \
    --cc=akpm@linux-foundation.org \
    --cc=da.gomez@samsung.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=ioworker0@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=p.raghav@samsung.com \
    --cc=ryan.roberts@arm.com \
    --cc=shy828301@gmail.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    --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