linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	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>, 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: Re: [PATCH 3/4] mm: prevent KSM from completely breaking VMA merging
Date: Mon, 19 May 2025 21:28:01 +0200	[thread overview]
Message-ID: <de02f1cc-558b-46c5-add9-5c55385c409a@redhat.com> (raw)
In-Reply-To: <fed73be7-6f34-48b9-a9c9-2fe5ad46f5ba@lucifer.local>

>>>>
>>>> So, assuming we could remove the VM_PFNMAP | VM_IO | VM_DONTEXPAND |
>>>> VM_MIXEDMAP constraint from vma_ksm_compatible(), could we simplify?
>>>
>>> Well I question removing this constraint for above reasons.
>>>
>>> At any rate, even if we _could_ this feels like a bigger change that we
>>> should come later.
>>
>> "bigger" -- it might just be removing these 4 flags from the check ;)
>>
>> I'll dig a bit more.
> 
> Right, but doing so would be out of scope here don't you think?

I'm fine with moving forward with this here. Just thinking how we can 
make more VMA merging "easily" possible and avoid the KSM magic in the 
mmap handling code.

(that early ksm check handling is rather ugly)

Your patch promises "prevent KSM from completely breaking VMA merging", 
and  I guess that's true: after this patch merging with at least anon 
and MAP_PRIVATE of shmem it's not broken anymore. :)

-- 
Cheers,

David / dhildenb



  parent reply	other threads:[~2025-05-19 19:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-19  8:51 [PATCH 0/4] mm: ksm: prevent KSM from entirely breaking VMA merging Lorenzo Stoakes
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 [this message]
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

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=de02f1cc-558b-46c5-add9-5c55385c409a@redhat.com \
    --to=david@redhat.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=chengming.zhou@linux.dev \
    --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=lorenzo.stoakes@oracle.com \
    --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).