From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Daniel Gomez <da.gomez@samsung.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"hughd@google.com" <hughd@google.com>,
"willy@infradead.org" <willy@infradead.org>,
"david@redhat.com" <david@redhat.com>,
"wangkefeng.wang@huawei.com" <wangkefeng.wang@huawei.com>,
"ying.huang@intel.com" <ying.huang@intel.com>,
"21cnbao@gmail.com" <21cnbao@gmail.com>,
"ryan.roberts@arm.com" <ryan.roberts@arm.com>,
"shy828301@gmail.com" <shy828301@gmail.com>,
"ziy@nvidia.com" <ziy@nvidia.com>,
"ioworker0@gmail.com" <ioworker0@gmail.com>,
Pankaj Raghav <p.raghav@samsung.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/6] mm: shmem: add multi-size THP sysfs interface for anonymous shmem
Date: Tue, 11 Jun 2024 10:04:31 +0800 [thread overview]
Message-ID: <6c7a8602-5b88-424c-a8c4-8a9502865d94@linux.alibaba.com> (raw)
In-Reply-To: <denilwdvfb772l432ezexwmy46rzv7disxhryf2ktqmtfk5khe@ghq3sohl5z3w>
On 2024/6/10 20:23, Daniel Gomez wrote:
> Hi Baolin,
> On Tue, Jun 04, 2024 at 06:17:47PM +0800, Baolin Wang 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". An 'inherit' option is added to ensure compatibility with these
>> global settings, and the options 'force' and 'deny' are dropped, which are
>> rather testing artifacts from the old ages.
>>
>> 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 | 23 ++++++
>> include/linux/huge_mm.h | 10 +++
>> mm/huge_memory.c | 11 +--
>> mm/shmem.c | 96 ++++++++++++++++++++++
>> 4 files changed, 132 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
>> index d414d3f5592a..b76d15e408b3 100644
>> --- a/Documentation/admin-guide/mm/transhuge.rst
>> +++ b/Documentation/admin-guide/mm/transhuge.rst
>> @@ -332,6 +332,29 @@ deny
>> force
>> Force the huge option on for all - very useful for testing;
>>
>> +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',
>> +and its value for each mTHP is essentially consistent with the global setting.
>> +An 'inherit' option is added to ensure compatibility with these global settings.
>> +Conversely, the options 'force' and 'deny' are dropped, which are rather testing
>> +artifacts from the old ages.
>> +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();
>> +
>> Need of application restart
>> ===========================
>>
>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> index 020e2344eb86..fac21548c5de 100644
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -6,6 +6,7 @@
>> #include <linux/mm_types.h>
>>
>> #include <linux/fs.h> /* only for vma_is_dax() */
>> +#include <linux/kobject.h>
>>
>> vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf);
>> int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
>> @@ -63,6 +64,7 @@ ssize_t single_hugepage_flag_show(struct kobject *kobj,
>> struct kobj_attribute *attr, char *buf,
>> enum transparent_hugepage_flag flag);
>> extern struct kobj_attribute shmem_enabled_attr;
>> +extern struct kobj_attribute thpsize_shmem_enabled_attr;
>>
>> /*
>> * Mask of all large folio orders supported for anonymous THP; all orders up to
>> @@ -265,6 +267,14 @@ unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma,
>> return __thp_vma_allowable_orders(vma, vm_flags, tva_flags, orders);
>> }
>>
>> +struct thpsize {
>> + struct kobject kobj;
>> + struct list_head node;
>> + int order;
>> +};
>> +
>> +#define to_thpsize(kobj) container_of(kobj, struct thpsize, kobj)
>> +
>> enum mthp_stat_item {
>> MTHP_STAT_ANON_FAULT_ALLOC,
>> MTHP_STAT_ANON_FAULT_FALLBACK,
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 8e49f402d7c7..1360a1903b66 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -449,14 +449,6 @@ static void thpsize_release(struct kobject *kobj);
>> static DEFINE_SPINLOCK(huge_anon_orders_lock);
>> static LIST_HEAD(thpsize_list);
>>
>> -struct thpsize {
>> - struct kobject kobj;
>> - struct list_head node;
>> - int order;
>> -};
>> -
>> -#define to_thpsize(kobj) container_of(kobj, struct thpsize, kobj)
>> -
>> static ssize_t thpsize_enabled_show(struct kobject *kobj,
>> struct kobj_attribute *attr, char *buf)
>> {
>> @@ -517,6 +509,9 @@ static struct kobj_attribute thpsize_enabled_attr =
>>
>> static struct attribute *thpsize_attrs[] = {
>> &thpsize_enabled_attr.attr,
>> +#ifdef CONFIG_SHMEM
>> + &thpsize_shmem_enabled_attr.attr,
>> +#endif
>> NULL,
>> };
>>
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index ae358efc397a..643ff7516b4d 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -131,6 +131,14 @@ struct shmem_options {
>> #define SHMEM_SEEN_QUOTA 32
>> };
>>
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> +static unsigned long huge_anon_shmem_orders_always __read_mostly;
>> +static unsigned long huge_anon_shmem_orders_madvise __read_mostly;
>> +static unsigned long huge_anon_shmem_orders_inherit __read_mostly;
>> +static unsigned long huge_anon_shmem_orders_within_size __read_mostly;
>> +static DEFINE_SPINLOCK(huge_anon_shmem_orders_lock);
>> +#endif
>
> Since we are also applying the new sysfs knob controls to tmpfs and anon mm,
> should we rename this to get rid of the anon prefix?
Sure. I want to do this in the patch set of mTHP support tmpfs
originally, but yes, I can just drop the 'anon' prefix as a preparation.
next prev parent reply other threads:[~2024-06-11 2:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 10:17 [PATCH v4 0/6] add mTHP support " Baolin Wang
2024-06-04 10:17 ` [PATCH v4 1/6] mm: memory: extend finish_fault() to support large folio Baolin Wang
2024-06-04 14:58 ` kernel test robot
2024-06-05 1:16 ` Baolin Wang
2024-06-04 10:17 ` [PATCH v4 2/6] mm: shmem: add THP validation for PMD-mapped THP related statistics Baolin Wang
2024-06-04 10:17 ` [PATCH v4 3/6] mm: shmem: add multi-size THP sysfs interface for anonymous shmem Baolin Wang
[not found] ` <CGME20240610122305eucas1p21bfd8a8c999b3fc8bfce04e5feea7bf7@eucas1p2.samsung.com>
2024-06-10 12:23 ` Daniel Gomez
2024-06-11 2:04 ` Baolin Wang [this message]
2024-06-04 10:17 ` [PATCH v4 4/6] mm: shmem: add mTHP support " Baolin Wang
[not found] ` <CGME20240610132756eucas1p1d892ccbabdb5f8fc4cff55c662f24d75@eucas1p1.samsung.com>
2024-06-10 13:27 ` Daniel Gomez
2024-06-11 2:42 ` Baolin Wang
2024-06-04 10:17 ` [PATCH v4 5/6] mm: shmem: add mTHP size alignment in shmem_get_unmapped_area Baolin Wang
2024-06-04 10:17 ` [PATCH v4 6/6] mm: shmem: add mTHP counters for anonymous shmem Baolin Wang
2024-06-04 23:50 ` [PATCH v4 0/6] add mTHP support " Andrew Morton
[not found] ` <CGME20240610121040eucas1p2ad07a27dec959bf1658ea9e5f0dd4697@eucas1p2.samsung.com>
2024-06-10 12:10 ` Daniel Gomez
2024-06-11 2:53 ` Baolin Wang
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=6c7a8602-5b88-424c-a8c4-8a9502865d94@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=21cnbao@gmail.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