linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
	Pedro Falcato <pfalcato@suse.de>,
	David Hildenbrand <david@redhat.com>,
	Xu Xin <xu.xin16@zte.com.cn>,
	Chengming Zhou <chengming.zhou@linux.dev>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: [PATCH 0/4] mm: ksm: prevent KSM from entirely breaking VMA merging
Date: Mon, 19 May 2025 09:51:38 +0100	[thread overview]
Message-ID: <cover.1747431920.git.lorenzo.stoakes@oracle.com> (raw)

When KSM-by-default is established using prctl(PR_SET_MEMORY_MERGE), this
defaults all newly mapped VMAs to having VM_MERGEABLE set, and thus makes
them available to KSM for samepage merging. It also sets VM_MERGEABLE in
all existing VMAs.

However this causes an issue upon mapping of new VMAs - the initial flags
will never have VM_MERGEABLE set when attempting a merge with adjacent VMAs
(this is set later in the mmap() logic), and adjacent VMAs will ALWAYS have
VM_MERGEABLE set.

This renders literally all VMAs in the virtual address space unmergeable.

To avoid this, this series performs the check for PR_SET_MEMORY_MERGE far
earlier in the mmap() logic, prior to the merge being attempted.

However we run into a complexity with the depreciated .mmap() callback - if
a driver hooks this, it might change flags thus adjusting KSM merge
eligibility.

This isn't a problem for brk(), where the VMA must be anonymous. However
for mmap() we are conservative - if the VMA is anonymous then we can always
proceed, however if not, we permit only shmem mappings and drivers which
implement .mmap_prepare().

If we can't be sure of the driver changing things, then we maintain the
same behaviour of performing the KSM check later in the mmap() logic (and
thus losing VMA mergeability).

Since the .mmap_prepare() hook is invoked prior to the KSM check, this
means we can always perform the KSM check early if it is present. Over time
as drivers are converted, we can do away with the later check altogether.

A great many use-cases for this logic will use anonymous or shmem memory at
any rate, as KSM is not supported for the page cache, and the driver
outliers in question are MAP_PRIVATE mappings of these files.

So this change should already cover the majority of actual KSM use-cases.

Lorenzo Stoakes (4):
  mm: ksm: have KSM VMA checks not require a VMA pointer
  mm: ksm: refer to special VMAs via VM_SPECIAL in ksm_compatible()
  mm: prevent KSM from completely breaking VMA merging
  tools/testing/selftests: add VMA merge tests for KSM merge

 include/linux/fs.h                 |  7 ++-
 include/linux/ksm.h                |  4 +-
 mm/ksm.c                           | 51 ++++++++++++-------
 mm/vma.c                           | 49 ++++++++++++++++++-
 tools/testing/selftests/mm/merge.c | 78 ++++++++++++++++++++++++++++++
 5 files changed, 166 insertions(+), 23 deletions(-)

--
2.49.0

             reply	other threads:[~2025-05-19  8:52 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-19  8:51 Lorenzo Stoakes [this message]
2025-05-19  8:51 ` [PATCH 1/4] mm: ksm: have KSM VMA checks not require a VMA pointer Lorenzo Stoakes
2025-05-19 17:40   ` David Hildenbrand
2025-05-20  3:14   ` Chengming Zhou
2025-05-19  8:51 ` [PATCH 2/4] mm: ksm: refer to special VMAs via VM_SPECIAL in ksm_compatible() Lorenzo Stoakes
2025-05-19 17:41   ` David Hildenbrand
2025-05-20  3:15   ` Chengming Zhou
2025-05-19  8:51 ` [PATCH 3/4] mm: prevent KSM from completely breaking VMA merging Lorenzo Stoakes
2025-05-19 13:08   ` Chengming Zhou
2025-05-19 13:13     ` Lorenzo Stoakes
2025-05-19 13:19   ` kernel test robot
2025-05-19 13:36     ` Lorenzo Stoakes
2025-05-19 18:00   ` David Hildenbrand
2025-05-19 18:04     ` David Hildenbrand
2025-05-19 19:02       ` Lorenzo Stoakes
2025-05-19 19:11         ` David Hildenbrand
2025-05-19 19:26           ` Lorenzo Stoakes
2025-05-19 19:29             ` David Hildenbrand
2025-05-19 18:52     ` Lorenzo Stoakes
2025-05-19 18:59       ` David Hildenbrand
2025-05-19 19:14         ` Lorenzo Stoakes
2025-05-19 19:18           ` Lorenzo Stoakes
2025-05-19 19:28           ` David Hildenbrand
2025-05-19 21:57       ` Andrew Morton
2025-05-20  5:25         ` Lorenzo Stoakes
2025-05-20  3:55   ` Chengming Zhou
2025-05-20  5:24     ` Lorenzo Stoakes
2025-05-19  8:51 ` [PATCH 4/4] tools/testing/selftests: add VMA merge tests for KSM merge Lorenzo Stoakes
2025-05-21  8:07   ` Chengming Zhou
2025-05-21  8:10     ` Lorenzo Stoakes
2025-05-19 11:53 ` [PATCH 0/4] mm: ksm: prevent KSM from entirely breaking VMA merging David Hildenbrand
2025-05-19 11:56   ` Lorenzo Stoakes
  -- strict thread matches above, loose matches on Subject: below --
2025-05-21 18:20 Lorenzo Stoakes
2025-05-21 18:23 ` Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1747431920.git.lorenzo.stoakes@oracle.com \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=chengming.zhou@linux.dev \
    --cc=david@redhat.com \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pfalcato@suse.de \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xu.xin16@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).