From: Joel Fernandes <joel@joelfernandes.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, Shuah Khan <shuah@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Kirill A Shutemov <kirill@shutemov.name>,
"Liam R. Howlett" <liam.howlett@oracle.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Kalesh Singh <kaleshsingh@google.com>,
Lokesh Gidra <lokeshgidra@google.com>
Subject: Re: [PATCH v3 1/6] mm/mremap: Optimize the start addresses in move_page_tables()
Date: Thu, 25 May 2023 15:51:23 -0400 [thread overview]
Message-ID: <CAEXW_YQO5-=4HRiZFiJ7ZsAHSLFEhHP29czqODFkH5mmVeqjZQ@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wiNUe7YjK9fmZk+2ZQhjLH-64WrkwnXO9813_iLuaFXuQ@mail.gmail.com>
Hi Linus,
On Wed, May 24, 2023 at 7:23 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Hmm. I'm still quite unhappy about your can_align_down().
>
> On Wed, May 24, 2023 at 8:32 AM Joel Fernandes (Google)
> <joel@joelfernandes.org> wrote:
> >
> > + /* If the masked address is within vma, we cannot align the address down. */
> > + if (vma->vm_start <= addr_masked)
> > + return false;
>
> I don't think this test is right.
>
> The test should not be "is the mapping still there at the point we
> aligned down to".
>
> No, the test should be whether there is any part of the mapping below
> the point we're starting with:
>
> if (vma->vm_start < addr_to_align)
> return false;
>
> because we can do the "expand the move down" *only* if it's the
> beginning of the vma (because otherwise we'd be moving part of the vma
> that precedes the address!)
You are right, I missed that. Funny I did think about this case you
mentioned. I will fix it in the next revision, thanks.
> (Alternatively, just make that "<" be "!=" - we're basically saying
> that we can expand moving ptes to a pmd boundary *only* if this vma
> starts at that point. No?).
Yes, I prefer the "!=" check. I will use that.
>
> > + cur = find_vma_prev(vma->vm_mm, vma->vm_start, &prev);
> > + if (!cur || cur != vma || !prev)
> > + return false;
>
> I've mentioned this test before, and I still find it actively misleading.
>
> First off, the "!cur || cur != vma" test is clearly redundant. We know
> 'vma' isn't NULL (we just dereferenced it!). So "cur != vma" already
> includes the "!cur" test.
>
> So that "!cur" part of the test simply *cannot* be sensible.
Ok, I agree with you now.
> And the "!prev" test still makes no sense to me. You tried to explain
> it to me earlier, and I clearly didn't get it. It seems actively
> wrong. I still think "!prev" should return true.
Yes, ok. Sounds good.
> You seemed to think that "!prev" couldn';t actually happen and would
> be a sign of some VM problem, but that doesn't make any sense to me.
> Of course !prev can happen - if "vma" is the first vma in the VM and
> there is no previous.
>
> It may be *rare*, but I still don't understand why you'd make that
> "there is no vma below us" mean "we cannot expand the move below us
> because there's something there".
>
> So I continue to think that this test should just be
>
> if (WARN_ON_ONCE(cur != vma))
> return false;
I agree with this now.
>
> because if it ever returns something that *isn't* the same as vma,
> then we do indeed have serious problems. But that WARN_ON_ONCE() shows
> that that's a "cannot happen" thing, not some kind of "if this happens
> than don't do it" test.
>
> and then the *real* test for "can we align down" should just be
>
> return !prev || prev->vm_end <= addr_masked;
Agreed, that's cleaner.
> Because while I think your code _works_, it really doesn't seem to
> make much sense as it stands in your patch. The tests are actively
> misleading. No?
True, your approach makes me want to improve on writing cleaner code
than being excessively paranoid. So thank you for that.
These patches have been tricky to get right so thank you for your
continued input and quick feedback.
I will add a test for the case you mentioned above where the address
to realign wasn't in the VMA's beginning.
thanks,
- Joel
next prev parent reply other threads:[~2023-05-25 19:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-24 15:32 [PATCH v3 0/6] Optimize mremap during mutual alignment within PMD Joel Fernandes (Google)
2023-05-24 15:32 ` [PATCH v3 1/6] mm/mremap: Optimize the start addresses in move_page_tables() Joel Fernandes (Google)
2023-05-24 23:23 ` Linus Torvalds
2023-05-25 19:51 ` Joel Fernandes [this message]
2023-05-24 15:32 ` [PATCH v3 2/6] mm/mremap: Allow moves within the same VMA Joel Fernandes (Google)
2023-05-24 15:32 ` [PATCH v3 3/6] selftests: mm: Fix failure case when new remap region was not found Joel Fernandes (Google)
2023-05-24 15:32 ` [PATCH v3 4/6] selftests: mm: Add a test for mutually aligned moves > PMD size Joel Fernandes (Google)
2023-05-24 15:32 ` [PATCH v3 5/6] selftests: mm: Add a test for remapping to area immediately after existing mapping Joel Fernandes (Google)
2023-05-24 15:32 ` [PATCH v3 6/6] selftests: mm: Add a test for remapping within a range Joel Fernandes (Google)
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='CAEXW_YQO5-=4HRiZFiJ7ZsAHSLFEhHP29czqODFkH5mmVeqjZQ@mail.gmail.com' \
--to=joel@joelfernandes.org \
--cc=kaleshsingh@google.com \
--cc=kirill@shutemov.name \
--cc=liam.howlett@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lokeshgidra@google.com \
--cc=lstoakes@gmail.com \
--cc=mhocko@suse.com \
--cc=paulmck@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
/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