From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: David Hildenbrand <david@redhat.com>,
Hugh Dickins <hughd@google.com>,
akpm@linux-foundation.org, ziy@nvidia.com,
Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com,
dev.jain@arm.com, baohua@kernel.org, zokeefe@google.com,
shy828301@gmail.com, usamaarif642@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/2] fix MADV_COLLAPSE issue if THP settings are disabled
Date: Wed, 25 Jun 2025 18:02:51 +0800 [thread overview]
Message-ID: <37fc3553-0d5a-4bdc-b473-cd740d47598e@linux.alibaba.com> (raw)
In-Reply-To: <ff3cc6bc-dd40-4b6b-a293-eedcc7c8eaf6@lucifer.local>
On 2025/6/25 17:31, Lorenzo Stoakes wrote:
> On Wed, Jun 25, 2025 at 04:52:03PM +0800, Baolin Wang wrote:
>>
>>
>> On 2025/6/25 16:37, Lorenzo Stoakes wrote:
>>> Yeah maybe the best way is to just have another tunable for this?
>>>
>>> /sys/kernel/mm/transparent_hugepage/disable_collapse perhaps?
>>>
>>> What do you think Hugh, Baolin?
>>
>> I think it's not necessary to find a way to disable madvise_collapse.
>> Essentially, it's a conflict between the semantics of madvise_collapse and
>> the '/sys/kernel/mm/transparent_hugepage/enabled' interface. We should reach
>> a consensus on the semantics first:
>>
>> Semantic 1: madv_collapse() should ignore any THP system settings, meaning
>> we need to update the 'never' semantics in
>> '/sys/kernel/mm/transparent_hugepage/enabled', which would only disable page
>> fault and khugepaged, not including madvise_collapse. If we agree on this,
>> then the 'never' for per-sized mTHP would have the same semantics, i.e.,
>> when I set 64K mTHP to 'always' and 2M mTHP to 'never', madvise_collapse
>> would still allow the collapse of 2M THP. We should document this clearly in
>> case users still want 64K mTHP from madvise_collapse.
>
> Right yeah, I mean this is in effect how things are now. So the task is
> documentation.
>
>>
>>
>> Semantic 2: madv_collapse() needs to respect THP system settings, which is
>> what my patch does. Never means never, and we would need to update the
>> documentation of madv_collapse() to make it clearer.
>
> Yes, and indeed this is the choice.
>
> I think, as David said, it comes down to whether we have a legit use case that
> truly relies on this.
>
>>> (One side note on PMD-sized MADV_COLLAPSE - this is basically completely
>>> useless for 64 KB page size arm64 systems where PMD's are 512 MB :)
>>>
>>> Thoughts Baolin?
>>
>> We should not collapse 512MB THP on 64K pagesize kernel. So seems
>> madv_collapse() can not work on 64K pagesize kernel.
>
> Well I don't think anything would prevent this now right? So MADV_COLLAPSE is
> pretty problematic on 64K pagesize kernels in general.
Yes, I don't mean it will prevent madvise_collapse(), just as you said
that it could be problematic (it's horrible to try to collapse 512MB).
> Anyway that's maybe a problem for another time :)
Yeah, should consider mTHP-compatible MADV_COLLAPSE.
next prev parent reply other threads:[~2025-06-25 10:03 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 1:40 [PATCH v4 0/2] fix MADV_COLLAPSE issue if THP settings are disabled Baolin Wang
2025-06-25 1:40 ` [PATCH v4 1/2] mm: huge_memory: disallow hugepages if the system-wide THP sysfs " Baolin Wang
2025-06-25 4:34 ` Dev Jain
2025-06-25 1:40 ` [PATCH v4 2/2] mm: shmem: disallow hugepages if the system-wide shmem " Baolin Wang
2025-06-25 5:53 ` [PATCH v4 0/2] fix MADV_COLLAPSE issue if THP " Hugh Dickins
2025-06-25 6:05 ` Dev Jain
2025-06-25 6:26 ` Baolin Wang
2025-06-25 6:49 ` Dev Jain
2025-06-25 6:55 ` Baolin Wang
2025-06-25 7:20 ` Lorenzo Stoakes
2025-06-25 7:34 ` David Hildenbrand
2025-06-25 7:55 ` Lorenzo Stoakes
2025-06-25 8:12 ` Lorenzo Stoakes
2025-06-25 8:24 ` David Hildenbrand
2025-06-25 8:37 ` Lorenzo Stoakes
2025-06-25 8:52 ` Baolin Wang
2025-06-25 9:31 ` Lorenzo Stoakes
2025-06-25 10:02 ` Baolin Wang [this message]
2025-06-25 10:07 ` David Hildenbrand
2025-06-25 10:15 ` Lorenzo Stoakes
2025-06-25 10:29 ` David Hildenbrand
2025-06-25 8:53 ` David Hildenbrand
2025-06-25 11:03 ` Usama Arif
2025-06-25 11:09 ` David Hildenbrand
2025-06-26 3:49 ` Hugh Dickins
2025-06-25 7:23 ` David Hildenbrand
2025-06-25 7:30 ` Lorenzo Stoakes
2025-06-25 7:36 ` David Hildenbrand
2025-06-25 7:42 ` Lorenzo Stoakes
2025-06-25 7:49 ` David Hildenbrand
2025-06-25 8:16 ` David Hildenbrand
2025-06-25 8:22 ` Lorenzo Stoakes
2025-06-25 8:40 ` David Hildenbrand
2025-06-25 8:45 ` Lorenzo Stoakes
2025-06-25 21:51 ` Hugh Dickins
2025-07-09 12:36 ` Lorenzo Stoakes
2025-07-10 1:58 ` 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=37fc3553-0d5a-4bdc-b473-cd740d47598e@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.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=shy828301@gmail.com \
--cc=usamaarif642@gmail.com \
--cc=ziy@nvidia.com \
--cc=zokeefe@google.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.