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 09:38:56 +0800 [thread overview]
Message-ID: <20200707013856.GA27805@L-31X9LVDL-1304.local> (raw)
In-Reply-To: <20200706100729.y2wbkpc4tyvjojzg@box>
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.
>> + if (extent > next - new_addr)
>> + extent = next - new_addr;
>> old_pmd = get_old_pmd(vma->vm_mm, old_addr);
>> if (!old_pmd)
>> continue;
>> @@ -301,9 +304,6 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
>>
>> if (pte_alloc(new_vma->vm_mm, new_pmd))
>> break;
>> - next = (new_addr + PMD_SIZE) & PMD_MASK;
>> - if (extent > next - new_addr)
>> - extent = next - new_addr;
>> move_ptes(vma, old_pmd, old_addr, old_addr + extent, new_vma,
>> new_pmd, new_addr, need_rmap_locks);
>> }
>> --
>> 2.20.1 (Apple Git-117)
>>
>
>--
> Kirill A. Shutemov
--
Wei Yang
Help you, Help me
next prev parent reply other threads:[~2020-07-07 1:39 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 [this message]
2020-07-07 10:47 ` Kirill A. Shutemov
2020-07-07 12:53 ` Wei Yang
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=20200707013856.GA27805@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