Re: [PATCH resend] ksm: add merge_only_zero_pages to merge only empty anonymous pages

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/10/26 02:34, Xu Xin (vivo) wrote:
> On Mon, Nov 09, 2026 at 06:41:39PM +0100, David Hildenbrand (Arm) wrote:
>> On 11/9/26 02:39, Xu Xin (vivo) wrote:
>>>
>>> Ha, fair question :) This came from our own investigation. We were looking
>>> into whether KSM can actually provide benefits on Android phones, and this
>>> observation came from real-world application workloads. To be fully honest:
>>> I did use an LLM to help polish the English wording of the commit description,
>>> but I carefully rechecked and verified every sentence myself..
>>
>> The reason why I ask is that this effectively disables most deduplication where
>> KSM was originally invented for: VMs running the same kernels, libaries,
>> executables etc.
> 
> Yes, it closes the original scenarios like KVM, so I wrote a Note to say that in
> commit description and Documentations. But it opens up some new application scenarios
>  — scenarios with high security and low cpu-consuming requirements, where merging
> zero pages alone can already bring benefits.
> 
>>
>> So yeah, disabling most deduplication shrinks side-channels ... by disabling the
>> core functionality of KSM, to dedupicate pages with the same content :)
>>
>>>
>>>
>>> We still keep the stable/unstable tree data structures, but zero-page merging
>>> does not participate in the stable/unstable tree search path. One more reason
>>> for keeping them is that merge_only_zero_page is designed as a dynamic knob
>>> that can be toggled at runtime, so when it is disabled KSM can fall back to
>>> the traditional full KSM behavior.
>>
>>
>> What's the memory overhead from keeping these datastructures in the
>> merge_only_zero_page-only path?
> 
> In the merge_only_zero_page-only path of current implementation, the main memory
> overhead comes from the ksm_rmap_items for non-zero pages, RB trees of stable and
> unstable, and mm_slots.
> 
> If the allocation of rmap_item can be avoided (following Tu Jinjiang’s idea), then
> only the stable_tree and unstable_tree remain, which are basically empty, and these
> overheads become so low that they are negligible. The mm_slots are essential so can't
> be avoid, but won't take up much memory.

Okay, so that's the right approach then.

-- 
Cheers,

David