From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59946C02193 for ; Tue, 4 Feb 2025 18:22:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D9ACA6B007B; Tue, 4 Feb 2025 13:22:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D4A5E6B0082; Tue, 4 Feb 2025 13:22:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C132F6B0088; Tue, 4 Feb 2025 13:22:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A0FA66B007B for ; Tue, 4 Feb 2025 13:22:10 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 22CFEC032A for ; Tue, 4 Feb 2025 18:22:10 +0000 (UTC) X-FDA: 83083081620.18.95B61EF Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf16.hostedemail.com (Postfix) with ESMTP id 51375180015 for ; Tue, 4 Feb 2025 18:22:08 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="UkwX/aqV"; spf=pass (imf16.hostedemail.com: domain of souravpanda@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=souravpanda@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738693328; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aSz+Mpfjd+1GQLf6rJaCKzhhx48MH1homfl4AQTtOvw=; b=vOo8Pin7nJ/i6N/BXjrmbr4kGG1WUYqt7dDzrgF4JzJFm4ylTjIZQlU9zqhhjfLxERfLJu wmkwUWuBp3rJgHEleMLs3kYLiTNRuv05Q5otE9Zrssv1XRxOY81yuZQ+jsKYQsjiYiVxGi T35KqZDPHA92rsq8yrfkUyW8ZHUW/oU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="UkwX/aqV"; spf=pass (imf16.hostedemail.com: domain of souravpanda@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=souravpanda@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738693328; a=rsa-sha256; cv=none; b=55Wom6IwtvCHeeggq1T1KMgK4zyd0oqQHhPTohEp3hJEXUweZUGowBqgmHA+7J8MYanyMp 5PSqYs9wg40qsR96HYmXAD3pTBCbjwM9xNzmHZQ2YDBcr60CN9Ma1GD/sW/coFGudht36L VubKq7CspBnpTEB+hXWBM7w/FCjXF2o= Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-467896541e1so355101cf.0 for ; Tue, 04 Feb 2025 10:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738693327; x=1739298127; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aSz+Mpfjd+1GQLf6rJaCKzhhx48MH1homfl4AQTtOvw=; b=UkwX/aqV5j4G3nzku05DQwCTmjQrXx91fDZpZUqPF0xIB7HPjH0fkzf6StC/Hg+rlM u6lhlbzxAP24WPK4rVc3Z7pQbyJ9bXGirfJ9aVxyVVgoPgXmdsEV9KLNvpm8Fsc1l8nV WFP85WcAkD3lz7JidPPR0vsVz0mbRzCb+I6AkgH0yTAXsOabhxzl8bxUoG6vNIWJNyWK FO54Ibcg2p9P+hbejkYA1nbfSLlQORIhkV4GARVdURrWnu3ZG0p+e7yCuoxtZdI9DgmE YJG+1IvNf8ob71vmRDu182YxO9o9A6u62e7f1hPhvDbSAyPVDZZ6IKWy0WBtbRt8OsZR ziug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738693327; x=1739298127; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aSz+Mpfjd+1GQLf6rJaCKzhhx48MH1homfl4AQTtOvw=; b=aOhTtyWRKck2xynczP99nxPSs/rjxOLFeA9CkOdlqhVC9FngXJRxzt7k3hREpnWf/H dFn6ahQEPEHOTcf/cjO9UjJmYVGnuqi/DGo0obInOyIRWVD71B4jJldlpE1GPq8U6519 XSf+7XIhO543kSFuuyxBuQotMb2GFSPt7efR1XcGkmaPkRJm+GhOLQ6eXma9x+9Yczbg dU4ri27Lpzg0UY++q93MvIKGYyjHe3Z3RrxRsRVqz2LwA6NeQoISs8v+qTPgFz45ckAw bO+DY4tebIoCuKc3ZYCodPSZfGOGPgMn0aXUu20/GGdnTMdKo0howXHVoyPcRTuGO/Bb Y32A== X-Forwarded-Encrypted: i=1; AJvYcCU90tpWLjvYEYmd+g+SCV8zA7jLnIVjsuRLbxI6uGsKJaojMLq161jhgz8cRbdDB9iIMxkTDOIuyg==@kvack.org X-Gm-Message-State: AOJu0YwRdDhghrgt5f/iJk1QjHJgSsg2g2C79qVr7XGdRhBtgpWsdJsE BbkYAsY4RKmBfQ5QPN+M6r/9WSLNrugTMF0LVQ6FUt4bf7liC7ckjEWtT11h9VuVddVGTQPYsVI JNPFxxFZP85pCt+j37QHIAMV65m/GvPqsxuvM X-Gm-Gg: ASbGncvVMQVTCEAeMQh3C0E4oQHrAzBDZDx+p2g6gcPTNf8WCuuknir6sAWGG4DYGxu prWbD+3+NsoxEFiR3GIa5TpLCqM2s3sPaoKsqmQcLgOXMNQqwcOIo22QW/dJ8S+Mj9N+L1wjLiD k1JqaPGDmcQAEejVYCfcq4yQt346gW X-Google-Smtp-Source: AGHT+IGPU4LpJiKn7ZALkkbDYUrCgnxsU7pLaHpPYHch4/VUyhIAEXjli19IZBVM+5nNYbVjWeiGn/tndevOIwW0rV8= X-Received: by 2002:ac8:7f4c:0:b0:46c:77a0:7714 with SMTP id d75a77b69052e-4701ab792c4mr4109391cf.21.1738693327235; Tue, 04 Feb 2025 10:22:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sourav Panda Date: Tue, 4 Feb 2025 10:21:56 -0800 X-Gm-Features: AWEUYZnwBcnSaQzGD3-dnSfLI4hJ0MyrMwUdvqD72d0Sk1F2QoMfAMf3onqdhDo Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] KSM Enhancements: Selective KSM To: David Hildenbrand Cc: lsf-pc@lists.linux-foundation.org, Linux-MM , Pavel Tatashin , Yu Zhao , shr@devkernel.io, David Rientjes Content-Type: multipart/alternative; boundary="000000000000251e91062d5516d3" X-Rspamd-Queue-Id: 51375180015 X-Stat-Signature: 45yw8eobg1fps6d3k9iekx41jbmshzzi X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738693328-104325 X-HE-Meta: U2FsdGVkX18XKBQr+SfqDGSkQjSaRCIuMKTZtPdKimqz2B36jaoGMK2xKATdNb5Tp+CgLCzDQfrI0RQ/LKVO9ZzwF4KbvOGqUmpqQlGFry3If2b7ydWGszE4h+EgGi0emH3WfDAUi+hZ35GbMDlcA8W+vC75s/FedRO/Bh3asuFuQhVjPH9XmZT3nm/aXuvPuHEeQDm3eOdXYQgMpeiVkVSv+yrToN1F7Mv4ZNDlQ/o0Ce08EIYFM2ILTe7TrlkgcIDJmGvT3K9dCnz/MMpTVDH/zJ6DY6R1Af3d05jT7Qj4P7Wnm1qSmGb49XLcfZKPv4vUn9xHCOHLVnx27roYqrUvYU0hm0uFg5H5YQvE4wAlTduwWogOFHC4AcCtVO0WXePLOPvX9yVxOO7iQpWrGHuqMCghwQXRRaY21ae6hHTSoZ8jWion24bEHmKsmQm2OsKpeBFz6cLncB+ywp3E2f0sImR+VEfGNIXGjz87KvyGA9BuE2kgYopNeymAjTOswFRBYLjo6Ax/BO1fGzcatGKH9uuoRjrZBFK6US8ySSQip4fwl6CIKKEh/aFAMXkcNn5YRiSKVUXc3oang3mV1GywJzwCIX26883C681q9RMy5mXhAwB+NdBHil9N3vvDD/2nBQqHJtnTNwUnGiazUeVPqOz1Fi/fDBGSXd1CNqbj/LU6dkMmNUGzaD0Cqi3idR5ND5vSXlKGhULJOImRWyxNilh/fakohSJyGsW7SQabagQI4rMgm0ohKlC91N+irYp4UENpg8Ni6KQujx97rghpdyNxYrC9UWIRyVBQUB5iidscRNunF20Ey7KW2CQqMj1k4ikXJW4xUdG4JisELrWKjsN3+x0Vl4KbxdvbPbZeGreiDVWbLZ66HIKAizD0SkbhcIVmxJMwYn9uS5q9FNJTYIg8oIGeGI8t+/rpGsSqvUtKy+Sw7hIx3yFP6wKkzFGm6vJxnzNv0cJ1wva JHB4EbAi DSAQ0sxIiozRJTqmOKLxCoa29Tu6FZ/cn2v2KdLB49gVxz20OLqjzlbCrBpKYXUNw66+CeenBAZgq0fS+BZhNKDEGTSDuQNNaB9F7H2dft4wq5umPhJm/0cA6+Yzj5rIkbYpk1VB50bcN/1Tz2+I7QR50zr11ZlUtQNx8rNnGklhWv52myRB1pUYXWpgRBlU3vQTHX2pF46FsmXaULJbH3oiOD0ollo6OB61KiMsrqGKjWGCaAxGAdvfSL2dSByFBhN3vtHFfwfhUheBO4QAKc5TJYxNG9sn7dylDzDMonvGOyDbHxTJfc9JhJcHOIdt3+3H40CDLEgtjHIzdkI9KXm6tEF/zTxmiX5fn7AO/eLxdysqwFJDZ+wti3k2XcTZf3UANbY2Ti+9VFN61PxrRCUimMg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.076256, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --000000000000251e91062d5516d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2025 at 1:44=E2=80=AFAM David Hildenbrand = 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 merge= d > > > > 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 > > --000000000000251e91062d5516d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 4, = 2025 at 1:44=E2=80=AFAM 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 mer= ging
>
> identical pages across processes. However, there are certain interface= and
>
> implementation aspect that prevents its deployment in our use case; wh= erein
>
> security and efficiency (CPU overhead - due to background scanning) ar= e of
>
> greater importance.
>
>
> We propose Selective KSM, a mechanism to control when the merging take= s
>
> place and what pages can be merged together. We do this by partitionin= g the
>
> merge-space as per security-domains and carryout the merging as part o= f a
>
> synchronous syscall. Doing so, we ensure sensitive-content is not merg= ed
>
> 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 an= y
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 rang= e you want merged. Furthermore, are not required to specify what to merge a= gainst in the same invocation (e.g., insert / search the unstable tree).=C2= =A0
=C2=A0

In particular, it proposed an interface:

- /proc/uksm/merge enables the merging of two pages given their process
=C2=A0 =C2=A0IDs and addresses.
- /proc/uksm/unmerge allows unmerging a previously merged KSM page.
- /proc/uksm/cmp provides a lightweight mechanism to check page content
=C2=A0 =C2=A0equivalence before invoking a merge operation.

[1]
https://lore.kernel.= org/linux-mm/20240329104035.62942-1-teawater@antgroup.com/T/

--
Cheers,

David / dhildenb

--000000000000251e91062d5516d3--