Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Xu Xin (vivo)" <xu.xin@linux.dev>, Jinjiang Tu <tujinjiang@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Chengming Zhou <chengming.zhou@linux.dev>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	"Liam R . Howlett" <liam.howlett@oracle.com>,
	linux-mm@kvack.org, linux-doc@vger.kernel.org,
	Huan Yang <link@vivo.com>, Wang Xiao <xiao.wang@vivo.com>
Subject: Re: [PATCH resend] ksm: add merge_only_zero_pages to merge only empty anonymous pages
Date: Mon, 9 Nov 2026 18:56:47 +0100	[thread overview]
Message-ID: <2199b816-e3b0-4f1f-aef4-e79ce71fd07a@kernel.org> (raw)
In-Reply-To: <avEpskVC/NRPFt4d@dgvxl46587.localhost.localdomain>

On 11/9/26 03:02, Xu Xin (vivo) wrote:
> On Sat, Nov 07, 2026 at 04:13:40PM +0800, Jinjiang Tu wrote:
>>
>> 在 2026/11/6 11:48, xu.xin@linux.dev 写道:
>>> From: "Xu Xin (vivo)" <xu.xin@linux.dev>
>>>
>>>    KSM side-channel exposure is desired. Many handset vendors may prefer
>>>    this knob, which can be used as a default fallback policy.
>>>
>>> - Not suitable for server and virtualization workloads containing many
>>>    non-zero duplicate pages, where vanilla KSM provides better memory
>>>    savings.
>>
>> It’s a coincidence that I’m also working on similar optimizations.
>> In our scenario, we have a MySQL instance with over 700 GB of anonymous
>> memory. Most of this memory belongs to the buffer pool, which caches
>> data from storage; these pages cannot be merged. Of the remaining memory,
>> around 15 GB is consumed by hashtables, which contain many zero-filled
>> pages that are eligible for merging to reduce memory footprint.
>>
>> When we enabled KSM for the entire MySQL instance, ksmd created rmap_item
>> metadata for each candidate page.The massive metadata overhead wiped out
>> any gains from page merging, and even resulted in a negative benefit.
>>
>> For this reason, I’m trying to make ksmd merge only zero pages. The goal
>> is to have ksmd skip scanning non-zero pages entirely, thereby avoiding
>> the rmap_item metadata cost introduced by scanning non-mergeable pages.
> 
> Skip generating ksm_rmap_item for non-zero pages ? That dose make sense to me.

Yes, we should avoid any such memory overhead in that case.

-- 
Cheers,

David


  parent reply	other threads:[~2026-11-09 17:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06  3:48 [PATCH resend] ksm: add merge_only_zero_pages to merge only empty anonymous pages xu.xin
2026-11-07  3:49 ` sashiko-bot
2026-11-07  8:13 ` Jinjiang Tu
2026-11-09  2:02   ` Xu Xin (vivo)
2026-11-09  3:17     ` Jinjiang Tu
2026-11-09 17:56     ` David Hildenbrand (Arm) [this message]
2026-11-09  7:58   ` Xu Xin (vivo)
2026-11-10  2:02     ` Jinjiang Tu
2026-11-07 18:28 ` David Hildenbrand (Arm)
2026-11-09  1:39   ` Xu Xin (vivo)
2026-11-09 17:41     ` David Hildenbrand (Arm)
2026-11-10  1:34       ` Xu Xin (vivo)
2026-11-10 11:54         ` David Hildenbrand (Arm)

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=2199b816-e3b0-4f1f-aef4-e79ce71fd07a@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=corbet@lwn.net \
    --cc=liam.howlett@oracle.com \
    --cc=link@vivo.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=tujinjiang@huawei.com \
    --cc=xiao.wang@vivo.com \
    --cc=xu.xin@linux.dev \
    /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