From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: David Hildenbrand <david@redhat.com>,
akpm@linux-foundation.org, hughd@google.com
Cc: lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com,
ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] mm: huge_memory: disallow hugepages if the system-wide THP sysfs settings are disabled
Date: Thu, 12 Jun 2025 20:45:11 +0800 [thread overview]
Message-ID: <97a67b74-d473-455e-a05e-c85fe45da008@linux.alibaba.com> (raw)
In-Reply-To: <953596b2-8749-493d-97eb-a5d8995d9ef8@redhat.com>
On 2025/6/12 16:51, David Hildenbrand wrote:
> On 12.06.25 09:51, Baolin Wang wrote:
>>
>>
>> On 2025/6/11 20:34, David Hildenbrand wrote:
>>> On 05.06.25 10:00, Baolin Wang wrote:
>>>> The MADV_COLLAPSE will ignore the system-wide Anon THP sysfs settings,
>>>> which
>>>> means that even though we have disabled the Anon THP configuration,
>>>> MADV_COLLAPSE
>>>> will still attempt to collapse into a Anon THP. This violates the rule
>>>> we have
>>>> agreed upon: never means never.
>>>>
>>>> Another rule for madvise, referring to David's suggestion: “allowing
>>>> for collapsing
>>>> in a VM without VM_HUGEPAGE in the "madvise" mode would be fine".
>>>>
>>>> To address this issue, should check whether the Anon THP configuration
>>>> is disabled
>>>> in thp_vma_allowable_orders(), even when the TVA_ENFORCE_SYSFS flag is
>>>> set.
>>>>
>>>> In summary, the current strategy is:
>>>>
>>>> 1. If always & orders == 0, and madvise & orders == 0, and
>>>> hugepage_global_enabled() == false
>>>> (global THP settings are not enabled), it means mTHP of that orders
>>>> are prohibited
>>>> from being used, then madvise_collapse() is forbidden for that orders.
>>>>
>>>> 2. If always & orders == 0, and madvise & orders == 0, and
>>>> hugepage_global_enabled() == true
>>>> (global THP settings are enabled), and inherit & orders == 0, it means
>>>> mTHP of that
>>>> orders are still prohibited from being used, thus madvise_collapse()
>>>> is not allowed
>>>> for that orders.
>>>>
>>>> Reviewed-by: Zi Yan <ziy@nvidia.com>
>>>> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>>>> ---
>>>> include/linux/huge_mm.h | 23 +++++++++++++++++++----
>>>> 1 file changed, 19 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>>> index 2f190c90192d..199ddc9f04a1 100644
>>>> --- a/include/linux/huge_mm.h
>>>> +++ b/include/linux/huge_mm.h
>>>> @@ -287,20 +287,35 @@ unsigned long thp_vma_allowable_orders(struct
>>>> vm_area_struct *vma,
>>>> unsigned long orders)
>>>> {
>>>> /* Optimization to check if required orders are enabled
>>>> early. */
>>>> - if ((tva_flags & TVA_ENFORCE_SYSFS) && vma_is_anonymous(vma)) {
>>>> - unsigned long mask = READ_ONCE(huge_anon_orders_always);
>>>> + if (vma_is_anonymous(vma)) {
>>>> + unsigned long always = READ_ONCE(huge_anon_orders_always);
>>>> + unsigned long madvise = READ_ONCE(huge_anon_orders_madvise);
>>>> + unsigned long inherit = READ_ONCE(huge_anon_orders_inherit);
>>>> + unsigned long mask = always | madvise;
>>>> +
>>>> + /*
>>>> + * If the system-wide THP/mTHP sysfs settings are disabled,
>>>> + * then we should never allow hugepages.
>>> > + */> + if (!(mask & orders) &&
>>> !(hugepage_global_enabled() && (inherit & orders)))
>>>> + return 0;
>>>
>>> I'm still trying to digest that. Isn't there a way for us to work with
>>> the orders,
>>> essentially masking off all orders that are forbidden globally. Similar
>>> to below, if !orders, then return 0?
>>> /* Orders disabled directly. */
>>> orders &= ~TODO;
>>> /* Orders disabled by inheriting from the global toggle. */
>>> if (!hugepage_global_enabled())
>>> orders &= ~READ_ONCE(huge_anon_orders_inherit);
>>>
>>> TODO is probably a -1ULL and then clearing always/madvise/inherit. Could
>>> add a simple helper for that
>>>
>>> huge_anon_orders_never
>>
>> I followed Lorenzo's suggestion to simplify the logic. Does that look
>> more readable?
>>
>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> index 2f190c90192d..3087ac7631e0 100644
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -265,6 +265,43 @@ unsigned long __thp_vma_allowable_orders(struct
>> vm_area_struct *vma,
>> unsigned long tva_flags,
>> unsigned long orders);
>>
>> +/* Strictly mask requested anonymous orders according to sysfs
>> settings. */
>> +static inline unsigned long __thp_mask_anon_orders(unsigned long
>> vm_flags,
>> + unsigned long tva_flags, unsigned long
>> orders)
>> +{
>> + unsigned long always = READ_ONCE(huge_anon_orders_always);
>> + unsigned long madvise = READ_ONCE(huge_anon_orders_madvise);
>> + unsigned long inherit = READ_ONCE(huge_anon_orders_inherit);
>> + bool inherit_enabled = hugepage_global_enabled();
>> + bool has_madvise = vm_flags & VM_HUGEPAGE;
>> + unsigned long mask = always | madvise;
>> +
>> + mask = always | madvise;
>> + if (inherit_enabled)
>> + mask |= inherit;
>> +
>> + /* All set to/inherit NEVER - never means never globally,
>> abort. */
>> + if (!(mask & orders))
>> + return 0;
>
> Still confusing. I am not sure if we would properly catch when someone
> specifies e.g., 2M and 1M, while we only have 2M disabled.
IIUC, Yes. In your case, we will only allow order 8 (1M mTHP).
> I would rewrite the function to only ever substract from "orders".
>
> ...
>
> /* Disallow orders that are set to NEVER directly ... */
> order &= (always | madvise | inherit);
>
> /* ... or through inheritance. */
> if (inherit_enabled)
> orders &= ~inherit;
Sorry, I didn't get you here.
If orders = THP_ORDERS_ALL_ANON, inherit = 0x200 (order 9), always and
madvise are 0, and inherit_enabled = true. Then orders will be 0 with
your logic. But we should allow order 9, right?
>
> /*
> * Otherwise, we only enforce sysfs settings if asked. In addition,
> * if the user sets a sysfs mode of madvise and if TVA_ENFORCE_SYSFS
> * is not set, we don't bother checking whether the VMA has VM_HUGEPAGE
> * set.
> */
> if (!orders || !(tva_flags & TVA_ENFORCE_SYSFS))
> return orders;
>
>> +
>> + /*
>> + * Otherwise, we only enforce sysfs settings if asked. In
>> addition,
>> + * if the user sets a sysfs mode of madvise and if
>> TVA_ENFORCE_SYSFS
>> + * is not set, we don't bother checking whether the VMA has
>> VM_HUGEPAGE
>> + * set.
>> + */
>> + if (!(tva_flags & TVA_ENFORCE_SYSFS))
>> + return orders;
>> +
>> + mask = always;
>> + if (has_madvise)
>> + mask |= madvise;
>> + if (hugepage_global_always() || (has_madvise && inherit_enabled))
>> + mask |= inherit;
>
> Similarly, this can maybe become (not 100% sure if I got it right, the
> condition above is confusing)
IMO, this is the original logic.
> if (!has_madvise) {
> /*
> * Without VM_HUGEPAGE, only allow orders that are set to
> * ALWAYS directly ...
> */
> order &= (always | inherit);
> /* ... or through inheritance. */
> if (!hugepage_global_always())
> orders &= ~inherit;
Ditto. I can not understand this too.
> }
>
next prev parent reply other threads:[~2025-06-12 12:45 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 8:00 [PATCH v2 0/2] fix MADV_COLLAPSE issue if THP settings are disabled Baolin Wang
2025-06-05 8:00 ` [PATCH v2 1/2] mm: huge_memory: disallow hugepages if the system-wide THP sysfs " Baolin Wang
2025-06-06 16:49 ` Dev Jain
2025-06-06 18:47 ` Dev Jain
2025-06-09 5:57 ` Baolin Wang
2025-06-07 11:55 ` Lorenzo Stoakes
2025-06-07 12:21 ` Lorenzo Stoakes
2025-06-09 6:18 ` Baolin Wang
2025-06-09 15:12 ` Lorenzo Stoakes
2025-06-09 6:10 ` Baolin Wang
2025-06-09 15:17 ` Lorenzo Stoakes
2025-06-11 6:59 ` Baolin Wang
2025-06-08 18:37 ` Nico Pache
2025-06-09 6:36 ` Baolin Wang
2025-06-11 12:34 ` David Hildenbrand
2025-06-12 7:51 ` Baolin Wang
2025-06-12 8:46 ` Dev Jain
2025-06-12 8:52 ` David Hildenbrand
2025-06-12 8:51 ` David Hildenbrand
2025-06-12 12:45 ` Baolin Wang [this message]
2025-06-12 13:05 ` David Hildenbrand
2025-06-12 13:25 ` Baolin Wang
2025-06-12 13:40 ` Baolin Wang
2025-06-12 13:27 ` Lorenzo Stoakes
2025-06-12 13:29 ` Lorenzo Stoakes
2025-06-12 14:13 ` Baolin Wang
2025-06-12 14:16 ` David Hildenbrand
2025-06-12 14:20 ` Lorenzo Stoakes
2025-06-12 14:09 ` David Hildenbrand
2025-06-12 14:49 ` Lorenzo Stoakes
2025-06-13 2:07 ` Baolin Wang
2025-06-13 5:18 ` Lorenzo Stoakes
2025-06-12 13:07 ` Lorenzo Stoakes
2025-06-12 13:13 ` David Hildenbrand
2025-06-12 13:31 ` Lorenzo Stoakes
2025-06-05 8:00 ` [PATCH v2 2/2] mm: shmem: disallow hugepages if the system-wide shmem " Baolin Wang
2025-06-07 12:14 ` Lorenzo Stoakes
2025-06-07 12:17 ` Lorenzo Stoakes
2025-06-09 6:34 ` Baolin Wang
2025-06-09 19:30 ` Lorenzo Stoakes
2025-06-09 6:31 ` Baolin Wang
2025-06-09 15:33 ` Lorenzo Stoakes
2025-06-11 7:02 ` Baolin Wang
2025-06-07 12:28 ` [PATCH v2 0/2] fix MADV_COLLAPSE issue if THP " Lorenzo Stoakes
2025-06-11 7:05 ` Baolin Wang
2025-06-13 14:23 ` Usama Arif
2025-06-13 14:29 ` Lorenzo Stoakes
2025-06-13 14:39 ` Usama Arif
2025-06-13 14:42 ` Lorenzo Stoakes
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=97a67b74-d473-455e-a05e-c85fe45da008@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=npache@redhat.com \
--cc=ryan.roberts@arm.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 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.