[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi1PKGsk-Nr_Jd1vHGqg5AjTUtJkeh9R-a9SN-H=i2-1A@mail.gmail.com>
Date: Thu, 16 Jul 2020 10:54:52 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: Joel Fernandes <joel@...lfernandes.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux-MM <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Naresh Kamboju <naresh.kamboju@...aro.org>,
William Kucharski <william.kucharski@...cle.com>
Subject: Re: [PATCHv2] mm: Fix warning in move_normal_pmd()
On Thu, Jul 16, 2020 at 6:16 AM Kirill A. Shutemov <kirill@...temov.name> wrote:
>
> It can also lead to performance regression: for small mremap() if only one
> side of the range got aligned and there's no PMD_SIZE range to move,
> kernel will still iterate over PTEs, but it would need to handle more
> pte_none()s than without the patch.
Ack, I've dropped the patch from my queue of experiments, because it
doesn't work for the case I wanted to do, and the other cases could
regress, as you say.
Plus considering how many problems that patch had, I decided it wasn't
as simple as I initially thought it would be anyway ;)
Joel - while it's gone from my mind, if you're still interested in
this, maybe you can do something _similar_ that patch, except perhaps
also start out checking that the initial size is large enough for this
to make sense even when one of the sides doesn't align, for example.
(It might be as simple as checking that the initial 'len' is at least
PMD_SIZE - then you're guaranteed that whichever side gets aligned,
it's not doing extra work because the other side didn't).
Linus
Powered by blists - more mailing lists