On 2025-02-27 21:51, Linus Torvalds wrote:
On Thu, 27 Feb 2025 at 18:31, Mathieu Desnoyers
<mathieu.desnoyers@xxxxxxxxxxxx> 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
