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

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

On 11/9/26 02:39, Xu Xin (vivo) wrote:
> On Sat, Nov 07, 2026 at 07:28:50PM +0100, David Hildenbrand (Arm) wrote:
>> On 11/6/26 04:48, xu.xin@linux.dev wrote:
>>> From: "Xu Xin (vivo)" <xu.xin@linux.dev>
>>>
>>> Add a new sysfs attribute, /sys/kernel/mm/ksm/merge_only_zero_pages,
>>> which, when enabled, makes ksmd merge only empty (zeroed) anonymous
>>> pages with the kernel zero page and skip the stable and unstable trees
>>> entirely for pages that carry data.
>>>
>>> The attribute requires use_zero_pages to be 1, and the two are kept
>>> consistent by symmetric constraints: it cannot be enabled while
>>> use_zero_pages is 0 (-EINVAL), and use_zero_pages cannot be turned
>>> off while it is active (-EBUSY). The new attribute can be changed at
>>> any time and is only effective for pages merged after the change.
>>>
>>> Benefits in three aspects
>>> =========================
>>> - Memory saving:
>>>   On memory-constrained systems such as Android and embedded devices,
>>>   zero-filled anonymous pages are the largest source of duplicate
>>>   anonymous memory. They are produced by userspace allocators: the
>>>   zeroing of freshly allocated Java objects and buffers in the ART heap
>>>   (new byte[]/int[], Bitmap buffers), calloc/memset in native code, and
>>>   preallocated media buffers. Merging them with the kernel zero page
>>>   frees a significant amount of physical memory, which matters as DRAM
>>>   costs keep rising. With this enabled, we measured 100MB–300MB saving
>>>   tested with several popular applications on aarch64 (Android).
>>>
>>> - CPU overhead reduction:
>>>   Merging only zero pages also reduces the overhead of ksmd. A page that
>>>   is not merged with the zero page carries data and can never be merged
>>>   with the zero page, so there is no point in searching the stable tree
>>>   or inserting it into the unstable tree for it. Skipping those tree
>>>   operations for data-bearing pages reduces both the CPU time and the
>>>   rhashtable memory footprint of ksmd, which makes zero page merging
>>>   practical on low-resource devices where full KSM scanning would be too
>>>   expensive.
>>>
>>> - Security:
>>>   Finally, this shrinks the KSM side-channel attack surface: only zero
>>>   pages are ever merged, so the sharing status of data-bearing pages is
>>>   no longer observable through KSM timing side channels.
>>
>> Lol. Did you come up with that or an LLM :)
> 
> 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.

So yeah, disabling most deduplication shrinks side-channels ... by disabling the
core functionality of KSM, to dedupicate pages with the same content :)

> 
>>
>>>
>>> Note
>>> =====
>>> - Suitable for Android, embedded and low-memory devices, where zero-page
>>>   deduplication is wanted but full KSM scanning is too costly, and reduced
>>>   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.
>>
>> I proposed something similar when I was still at RH. My concern back then was
>> that we don't want/need all of the stable/unstable trees.
>>
>> IIUC that's all still in place in your implementation, right?
> 
> 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?


-- 
Cheers,

David