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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 28.02.25 16:01, Mathieu Desnoyers wrote:
On 2025-02-28 08:59, David Hildenbrand wrote:
On 28.02.25 06:17, Linus Torvalds wrote:
On Thu, 27 Feb 2025 at 19:03, Mathieu Desnoyers
<mathieu.desnoyers@xxxxxxxxxxxx> wrote:

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.

No, absolutely. The only point (for me) for your new synchronous one
would be if it replaced the kernel thread async scanning, which would
make the old user space interface basically pointless.

But I don't actually know who uses KSM right now. My reaction really
comes from a "it's not nice code in the kernel", not from any actual
knowledge of the users.

Maybe it works really well in some cloud VM environment, and we're
stuck with it forever.

Exactly that; and besides the VM use-case, lately people stated using it
in the context of interpreters (IIRC inside Meta) quite successfully as
well.


I suspect that SKSM is a better fit for JIT and code patching than KSM,
because user-space knows better when a set of pages is going to become
invariant for a long time and thus benefit from merging. This removes
the background scanning from the picture.
> > Does the interpreter use-case require background scanning, or does
it know when a set of pages are meant to become invariant for a long
time ?

To make the JIT/interpreter use case happy, people wanted ways to *force* KSM on for *the whole process*, not just individual VMAs like the traditional VM use case would have done.

I recall one of the reasons being that you don't really want to modify your JIT/interpreter to just make KSM work.

See [1] "KSM at Meta" for some details, and in general, optimization work to adapt KSM to new use cases.

Regarding some concerns you raised, Stefan did a lot of optimization work like "smart scanning" (slide "Optimization - Smart Scan (6.7)") to reduce the scanning overhead and make it much more efficient.

So people started optimizing for that already and got pretty good results.

[1] https://lpc.events/event/17/contributions/1625/attachments/1320/2649/KSM.pdf

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux