Re: [RFC PATCH 0/2] SKSM: Synchronous Kernel Samepage Merging

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2025-02-27 21:51, Linus Torvalds wrote:
> On Thu, 27 Feb 2025 at 18:31, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>>
>> This series introduces SKSM, a new page deduplication ABI,
>> aiming to fix the limitations inherent to the KSM ABI.
> 
> So I'm not interested in seeing *another* KSM version.
> 
> Because I absolutely do *NOT* want a new chapter in the saga of SLUB
> vs SLAB vs SLOB.
> 
> However, if the feeling is that this can *replace* the current horror
> that is KSM, I'm a lot more interested. I suspect our current KSM
> model has largely been a failure, and this might be "good enough".
I'd be fine with SKSM replacing KSM entirely. However, I don't
think we should try to re-implement the existing KSM userspace ABIs
over SKSM. I suspect that much of the problems KSM has today are
caused by the semantic of the ABI it exposes, which were targeted
solely for a host deduplicating guest VMs memory use-case.

KSM tracks memory meant to be mergeable on an ongoing
basis with a worker thread:

   madvise(2) MADV_{UN,}MERGEABLE
   prctl(2) PR_{SET,GET}_MEMORY_MERGE (security concern)
   ~2.5k LOC exclusing ksm-common code
   requires parameter fine-tuning from sysadmin

SKSM gets the hint from userspace that memory is a good
candidate for merging in its current state and is expected
to stay invariant:

   madvise(2) MADV_MERGE
   ~100 LOC exclusing ksm-common code

The main reason why SKSM could be implemented without all the
scanning complexity is because of this simpler ABI.

Thanks for the feedback!

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com