Re: [LSF/MM/BPF TOPIC] KSM Enhancements: Selective KSM

[Sourav Panda <souravpanda@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Tue, Feb 4, 2025 at 1:44 AM David Hildenbrand <david@redhat.com> wrote:

> On 01.02.25 03:15, Sourav Panda wrote:
> > Hi,
>
> Hi,
>
> >
> >
> > KSM is a powerful tool for deduplicating memory, reducing usage by
> merging
> >
> > identical pages across processes. However, there are certain interface
> and
> >
> > implementation aspect that prevents its deployment in our use case;
> wherein
> >
> > security and efficiency (CPU overhead - due to background scanning) are
> of
> >
> > greater importance.
> >
> >
> > We propose Selective KSM, a mechanism to control when the merging takes
> >
> > place and what pages can be merged together. We do this by partitioning
> the
> >
> > merge-space as per security-domains and carryout the merging as part of a
> >
> > synchronous syscall. Doing so, we ensure sensitive-content is not merged
> >
> > with non-sensitive content.
>
> I'll note that there was an RFC for uKSM [1] last year. Unfortunately, I
> didn't have time to look into it in more detail, and there was never any
> push for it.
>

Thank you David. I took a look at it, one major callout would be it is
extremely fine grained wherein you specify the exact 2 pages you want to
have merged. I prefer triggering a merge at a coarser granularity wherein
you just specify the address range you want merged. Furthermore, are not
required to specify what to merge against in the same invocation (e.g.,
insert / search the unstable tree).


>
> In particular, it proposed an interface:
>
> - /proc/uksm/merge enables the merging of two pages given their process
>    IDs and addresses.
> - /proc/uksm/unmerge allows unmerging a previously merged KSM page.
> - /proc/uksm/cmp provides a lightweight mechanism to check page content
>    equivalence before invoking a merge operation.
>
> [1]
>
> https://lore.kernel.org/linux-mm/20240329104035.62942-1-teawater@antgroup.com/T/
>
> --
> Cheers,
>
> David / dhildenb
>
>

[-- Attachment #2: Type: text/html, Size: 2784 bytes --]