All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: david@kernel.org
Cc: lance.yang@linux.dev, npache@redhat.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, yuzhao@google.com,
	usamaarif642@gmail.com, baohua@kernel.org, dev.jain@arm.com,
	ryan.roberts@arm.com, liam@infradead.org,
	baolin.wang@linux.alibaba.com, ziy@nvidia.com, ljs@kernel.org,
	akpm@linux-foundation.org
Subject: Re: [RFC] mm: restrict zero-page remapping to underused THP splits
Date: Mon, 18 May 2026 17:08:20 +0800	[thread overview]
Message-ID: <20260518090820.8101-1-lance.yang@linux.dev> (raw)
In-Reply-To: <cf552999-0b17-4abf-889e-2400c28628a9@kernel.org>


On Mon, May 18, 2026 at 10:24:26AM +0200, David Hildenbrand (Arm) wrote:
>On 5/14/26 10:11, Lance Yang wrote:
>> 
>> On Tue, May 12, 2026 at 09:02:38PM +0200, David Hildenbrand (Arm) wrote:
>>> On 5/12/26 20:36, Nico Pache wrote:
>>>> On Tue, May 12, 2026 at 1:05 AM David Hildenbrand (Arm)
>>>> <david@kernel.org> wrote:
>>>>
>>>> I meant before b1f202060afe ("mm: remap unused subpages to shared
>>>> zeropage when splitting isolated thp"). Sorry, I should have been more
>>>> specific.
>>>>
>>>> As in before the underutilized shrinker (and commit b1f202060afe), we
>>>> had the exact problem you describe above and no way to handle it.
>>>> Correct?
>>>
>>> Right. That's why the underused shrinker was added, to directly free pages that
>>> have been over-allocated with a THP, but are actually never "used" (remain zero).
>>>
>>>>
>>>> I guess at reclaim THPs would be split and we would swap out a zero filled page?
>>> We don't necessarily split during swapout, we try to swap out the THP if
>>> supported. But yes, that can happen.
>>>
>>> I'm more thinking about other reasons to split a THP (e.g., migration, partial
>>> MADV_PAGEOUT/MADV_COLD/MADV_FREE), where the behavior would be changed.
>> 
>> Yeah. Today any successful anon split gets TTU_USE_SHARED_ZEROPAGE. Would
>> it be better to make KSM opt out, so other split paths keep the behavior
>> they have today?
>> 
>> That way we do not have to worry about changing anything else at the
>> same time :D
>
>This is (1) here:
>
>https://lore.kernel.org/all/04ea0e68-de56-49c4-8c9f-1734139d5e7f@kernel.org/
>
>There will still be interaction between both mechanisms. So I'd prefer that in
>VM_MERGEABLE sections with KSM enabled, only KSM would take care of deduplicating.

Cool. I'd go with that approach as well. It should avoid unexpected
interaction between the two :)

That should keep VM_MERGEABLE VMAs under KSM's control, while leaving
the other split paths unchanged for now.

Cheers, Lance


  reply	other threads:[~2026-05-18  9:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08 17:05 [RFC] mm: restrict zero-page remapping to underused THP splits Nico Pache
2026-05-08 21:32 ` David Hildenbrand (Arm)
2026-05-09  8:25   ` Lance Yang
2026-05-10 11:39   ` Usama Arif
2026-05-11  6:36     ` David Hildenbrand (Arm)
2026-05-11 13:10       ` Usama Arif
2026-05-11 13:42         ` David Hildenbrand (Arm)
2026-05-11 13:44           ` David Hildenbrand (Arm)
2026-05-11 14:15             ` Usama Arif
2026-05-11 18:40   ` Nico Pache
2026-05-12  7:05     ` David Hildenbrand (Arm)
2026-05-12 18:36       ` Nico Pache
2026-05-12 19:02         ` David Hildenbrand (Arm)
2026-05-14  8:11           ` Lance Yang
2026-05-18  8:24             ` David Hildenbrand (Arm)
2026-05-18  9:08               ` Lance Yang [this message]
2026-06-08 10:34   ` Nico Pache
2026-06-08 11:14     ` David Hildenbrand (Arm)
2026-06-08 11:26       ` Nico Pache
2026-05-09  3:21 ` Lance Yang
2026-05-11 18:42   ` Nico Pache

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=20260518090820.8101-1-lance.yang@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=npache@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=usamaarif642@gmail.com \
    --cc=yuzhao@google.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.