Re: [PATCH 1/4] ksm: add only_merge_zero_pages to merge only empty anonymous pages

[David Hildenbrand (Arm)]

On 11/10/26 08:44, Xu Xin (vivo) wrote:
> Add a new sysfs attribute, /sys/kernel/mm/ksm/only_merge_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). Both store handlers take
> ksm_thread_mutex around their check-and-set so that a concurrent write
> to the two attributes cannot leave use_zero_pages=0 and
> only_merge_zero_pages=1, a state in which ksmd would scan and checksum
> pages but never merge any. 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.
> 
> 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.
> 
> Signed-off-by: Xu Xin (vivo) <xu.xin@xxxxxxxxx>
> Reviewed-by: Huan Yang <link@xxxxxxxx>
> Cc: Wang Xiao <xiao.wang@xxxxxxxx>
> ---

See my reply to #2. I think the overall feature makes sense, but reusing all of
KSM infrastructure just to deduplicate zero-filled pages looks suboptimal.

Please investigate how we could selectively reuse some pieces to just scan +
dedulicate zero-filled pages, avoiding the whole rmap item stuff etc.

-- 
Cheers,

David