linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@linux.alibaba.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Wei Yang <richard.weiyang@linux.alibaba.com>,
	akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
	yang.shi@linux.alibaba.com, vbabka@suse.cz, willy@infradead.org,
	thomas_os@shipmail.org, thellstrom@vmware.com,
	anshuman.khandual@arm.com, sean.j.christopherson@intel.com,
	aneesh.kumar@linux.ibm.com, peterx@redhat.com, walken@google.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	digetx@gmail.com
Subject: Re: [RESEND Patch v2 3/4] mm/mremap: calculate extent in one place
Date: Tue, 7 Jul 2020 20:53:24 +0800	[thread overview]
Message-ID: <20200707125324.GA32982@L-31X9LVDL-1304.local> (raw)
In-Reply-To: <20200707104722.j3awgkz4ncgm2bss@box>

On Tue, Jul 07, 2020 at 01:47:22PM +0300, Kirill A. Shutemov wrote:
>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)?
>

To be honest, I don't like this which makes the code not that straight
forward. And when you look into the definition of pxd_addr_end(), they use the
format of ((addr + PXD_SIZE) & PXD_MASK) too.

I have another alternative to clean up this part with the help of
pmd_addr_end(). If you agree, I would like to append the following change in
next version to cleanup the next/extent staff especially.

Author: Wei Yang <richard.weiyang@linux.alibaba.com>
Date:   Tue Jul 7 17:42:49 2020 +0800

    mm/mremap: use pmd_addr_end to calculate extent

diff --git a/mm/mremap.c b/mm/mremap.c
index f5f17d050617..76e7fdf567c3 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -237,11 +237,12 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
 		unsigned long new_addr, unsigned long len,
 		bool need_rmap_locks)
 {
-	unsigned long extent, next, old_end;
+	unsigned long extent, old_next, new_next, old_end, new_end;
 	struct mmu_notifier_range range;
 	pmd_t *old_pmd, *new_pmd;
 
 	old_end = old_addr + len;
+	new_end = new_addr + len;
 	flush_cache_range(vma, old_addr, old_end);
 
 	mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
@@ -250,14 +251,11 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
 
 	for (; old_addr < old_end; old_addr += extent, new_addr += extent) {
 		cond_resched();
-		next = (old_addr + PMD_SIZE) & PMD_MASK;
-		/* even if next overflowed, extent below will be ok */
-		extent = next - old_addr;
-		if (extent > old_end - old_addr)
-			extent = old_end - old_addr;
-		next = (new_addr + PMD_SIZE) & PMD_MASK;
-		if (extent > next - new_addr)
-			extent = next - new_addr;
+
+		old_next = pmd_addr_end(old_addr, old_end);
+		new_next = pmd_addr_end(new_addr, new_end);
+		extent = min((old_next - old_addr), (new_next - new_addr));
+
 		old_pmd = get_old_pmd(vma->vm_mm, old_addr);
 		if (!old_pmd)
 			continue;

>-- 
> Kirill A. Shutemov

-- 
Wei Yang
Help you, Help me


  reply	other threads:[~2020-07-07 12:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-26 13:52 [RESEND Patch v2 0/4] mm/mremap: cleanup move_page_tables() a little Wei Yang
2020-06-26 13:52 ` [RESEND Patch v2 1/4] mm/mremap: format the check in move_normal_pmd() same as move_huge_pmd() Wei Yang
2020-07-06 10:06   ` Kirill A. Shutemov
2020-06-26 13:52 ` [RESEND Patch v2 2/4] mm/mremap: it is sure to have enough space when extent meets requirement Wei Yang
2020-06-26 13:52 ` [RESEND Patch v2 3/4] mm/mremap: calculate extent in one place Wei Yang
2020-07-06 10:07   ` Kirill A. Shutemov
2020-07-07  1:38     ` Wei Yang
2020-07-07 10:47       ` Kirill A. Shutemov
2020-07-07 12:53         ` Wei Yang [this message]
2020-06-26 13:52 ` [RESEND Patch v2 4/4] mm/mremap: start addresses are properly aligned Wei Yang
2020-07-06 10:08 ` [RESEND Patch v2 0/4] mm/mremap: cleanup move_page_tables() a little Kirill A. Shutemov
2020-07-06 22:06   ` Wei Yang
2020-07-06 23:04     ` Andrew Morton

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=20200707125324.GA32982@L-31X9LVDL-1304.local \
    --to=richard.weiyang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=digetx@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=thellstrom@vmware.com \
    --cc=thomas_os@shipmail.org \
    --cc=vbabka@suse.cz \
    --cc=walken@google.com \
    --cc=willy@infradead.org \
    --cc=yang.shi@linux.alibaba.com \
    /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