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 15:59, Sean Christopherson wrote:
On Fri, Feb 28, 2025, 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.

Does Red Hat (or any other KVM supporters) actually recommend using KSM for VMs
in cloud environments?

Private clouds yes, that's where it is most commonly used for. I would assume that nobody for

For example, there is some older documentation here:

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/virtualization_administration_guide/chap-ksm#chap-KSM

which touches on the security aspects:

"The page deduplication technology (used also by the KSM implementation) may introduce side channels that could potentially be used to leak information across multiple guests. In case this is a concern, KSM can be disabled on a per-guest basis."


The security implications of scanning guest memory and having co-tenant VMs share
mappings (should) make it a complete non-starter for any scenario where VMs and/or
their workloads are owned by third parties.

Jep.


I can imagine there might be first-party use cases, but I would expect many/most
of those to be able to explicitly share mappings, which would provide far, far
better power and performance characteristics.

Note that KSM can be very efficient when you have multiple VMs running the same kernel,executable,libraries etc. If my memory doesn't trick me, that's precisely for what it was originally invented, and how it is getting used today in the context of VMs.

For example, QEMU will mark all guest memory is mergeable using MADV, to limit the deduplicaton to guest RAM only.

--
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