From: Johannes Weiner <hannes@cmpxchg.org>
To: Stefan Roesch <shr@devkernel.io>
Cc: kernel-team@fb.com, linux-mm@kvack.org, riel@surriel.com,
	mhocko@suse.com, david@redhat.com,
	linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org,
	akpm@linux-foundation.org
Subject: Re: [PATCH v3 1/3] mm: add new api to enable ksm per process
Date: Wed, 8 Mar 2023 23:59:10 -0500	[thread overview]
Message-ID: <20230309045910.GD476158@cmpxchg.org> (raw)
In-Reply-To: <qvqwbkl2zxui.fsf@dev0134.prn3.facebook.com>
On Wed, Mar 08, 2023 at 02:16:36PM -0800, Stefan Roesch wrote:
> Johannes Weiner <hannes@cmpxchg.org> writes:
> > On Thu, Feb 23, 2023 at 08:39:58PM -0800, Stefan Roesch wrote:
> >> @@ -2405,8 +2417,20 @@ static struct ksm_rmap_item *scan_get_next_rmap_item(struct page **page)
> >>  		goto no_vmas;
> >>
> >>  	for_each_vma(vmi, vma) {
> >> -		if (!(vma->vm_flags & VM_MERGEABLE))
> >> +		if (!vma_ksm_mergeable(vma))
> >>  			continue;
> >> +		if (!(vma->vm_flags & VM_MERGEABLE)) {
> >
> > IMO, the helper obscures the interaction between the vma flag and the
> > per-process flag here. How about:
> >
> > 		if (!(vma->vm_flags & VM_MERGEABLE)) {
> > 			if (!test_bit(MMF_VM_MERGE_ANY, &vma->vm_mm->flags))
> > 				continue;
> >
> > 			/*
> > 			 * With per-process merging enabled, have the MM scan
> > 			 * enroll any existing and new VMAs on the fly.
> > 			 *
> > 			ksm_madvise();
> > 		}
> >
> >> +			unsigned long flags = vma->vm_flags;
> >> +
> >> +			/* madvise failed, use next vma */
> >> +			if (ksm_madvise(vma, vma->vm_start, vma->vm_end, MADV_MERGEABLE, &flags))
> >> +				continue;
> >> +			/* vma, not supported as being mergeable */
> >> +			if (!(flags & VM_MERGEABLE))
> >> +				continue;
> >> +
> >> +			vm_flags_set(vma, VM_MERGEABLE);
> >
> > I don't understand the local flags. Can't it pass &vma->vm_flags to
> > ksm_madvise()? It'll set VM_MERGEABLE on success. And you know it
> > wasn't set before because the whole thing is inside the !set
> > branch. The return value doesn't seem super useful, it's only the flag
> > setting that matters:
> >
> > 			ksm_madvise(vma, vma->vm_start, vma->vm_end, MADV_MERGEABLE, &vma->vm_flags);
> > 			/* madvise can fail, and will skip special vmas (pfnmaps and such) */
> > 			if (!(vma->vm_flags & VM_MERGEABLE))
> > 				continue;
> >
> 
> vm_flags is defined as const. I cannot pass it directly inside the
> function, this is the reason, I'm using a local variable for it.
Oops, good catch.
However, while looking at the flag helpers, I'm also realizing that
modifications requires the mmap_sem in write mode, which this code
doesn't. This function might potentially scan the entire process
address space, so you can't just change the lock mode, either.
Staring more at this, do you actually need to set VM_MERGEABLE on the
individual vmas? There are only a few places that check VM_MERGEABLE,
and AFAICS they can all just check for MMF_VM_MERGE_ANY also.
You'd need to factor out the vma compatibility checks from
ksm_madvise(), and skip over special vmas during the mm scan. But
those tests are all stable under the read lock, so that's fine.
The other thing ksm_madvise() does is ksm_enter() - but that's
obviously not needed from inside the loop over ksm_enter'd mms. :)
next prev parent reply	other threads:[~2023-03-09  4:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24  4:39 [PATCH v3 0/3] mm: process/cgroup ksm support Stefan Roesch
2023-02-24  4:39 ` [PATCH v3 1/3] mm: add new api to enable ksm per process Stefan Roesch
2023-03-08 16:47   ` Johannes Weiner
2023-03-08 22:16     ` Stefan Roesch
2023-03-09  4:59       ` Johannes Weiner [this message]
2023-03-09 22:33         ` Stefan Roesch
2023-02-24  4:39 ` [PATCH v3 2/3] mm: add new KSM process and sysfs knobs Stefan Roesch
2023-02-24  4:40 ` [PATCH v3 3/3] selftests/mm: add new selftests for KSM Stefan Roesch
2023-02-26  5:30   ` Andrew Morton
2023-02-27 17:19     ` Stefan Roesch
2023-02-27 17:24       ` Mathieu Desnoyers
2023-02-26  5:08 ` [PATCH v3 0/3] mm: process/cgroup ksm support Andrew Morton
2023-02-27 17:13   ` Stefan Roesch
2023-03-07 18:48   ` Stefan Roesch
2023-03-08 17:01 ` David Hildenbrand
2023-03-08 17:30   ` Johannes Weiner
2023-03-08 18:41     ` David Hildenbrand
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=20230309045910.GD476158@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=kernel-team@fb.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=riel@surriel.com \
    --cc=shr@devkernel.io \
    /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).