lkml.org 
[lkml]   [2020]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RESEND Patch v2 3/4] mm/mremap: calculate extent in one place
On Tue, Jul 07, 2020 at 09:38:56AM +0800, Wei Yang wrote:
> On Mon, Jul 06, 2020 at 01:07:29PM +0300, Kirill A. Shutemov wrote:
> >On Fri, Jun 26, 2020 at 09:52:15PM +0800, Wei Yang wrote:
> >> Page tables is moved on the base of PMD. This requires both source
> >> and destination range should meet the requirement.
> >>
> >> Current code works well since move_huge_pmd() and move_normal_pmd()
> >> would check old_addr and new_addr again. And then return to move_ptes()
> >> if the either of them is not aligned.
> >>
> >> In stead of calculating the extent separately, it is better to calculate
> >> in one place, so we know it is not necessary to try move pmd. By doing
> >> so, the logic seems a little clear.
> >>
> >> Signed-off-by: Wei Yang <richard.weiyang@linux.alibaba.com>
> >> Tested-by: Dmitry Osipenko <digetx@gmail.com>
> >> ---
> >> mm/mremap.c | 6 +++---
> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/mm/mremap.c b/mm/mremap.c
> >> index de27b12c8a5a..a30b3e86cc99 100644
> >> --- a/mm/mremap.c
> >> +++ b/mm/mremap.c
> >> @@ -258,6 +258,9 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
> >> extent = next - old_addr;
> >> if (extent > old_end - old_addr)
> >> extent = old_end - old_addr;
> >> + next = (new_addr + PMD_SIZE) & PMD_MASK;
> >
> >Please use round_up() for both 'next' calculations.
> >
>
> I took another close look into this, seems this is not a good suggestion.
>
> round_up(new_addr, PMD_SIZE)
>
> would be new_addr when new_addr is PMD_SIZE aligned, which is not what we
> expect.

Maybe round_down(new_addr + PMD_SIZE, PMD_SIZE)?

--
Kirill A. Shutemov

\
 
 \ /
  Last update: 2020-07-07 12:49    [W:1.078 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site