lkml.org 
[lkml]   [2018]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 1/2] mm: migration: fix migration of huge PMD shared pages
From
Date
On 08/23/2018 05:48 AM, Michal Hocko wrote:
> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
> [...]
>
> OK, after burning myself when trying to be clever here it seems like
> your proposed solution is indeed simpler.
>
>> +bool huge_pmd_sharing_possible(struct vm_area_struct *vma,
>> + unsigned long *start, unsigned long *end)
>> +{
>> + unsigned long check_addr = *start;
>> + bool ret = false;
>> +
>> + if (!(vma->vm_flags & VM_MAYSHARE))
>> + return ret;
>> +
>> + for (check_addr = *start; check_addr < *end; check_addr += PUD_SIZE) {
>> + unsigned long a_start = check_addr & PUD_MASK;
>> + unsigned long a_end = a_start + PUD_SIZE;
>
> I guess this should be rather in HPAGE_SIZE * PTRS_PER_PTE units as
> huge_pmd_unshare does.

Sure, I can do that.

However, I consider the statement making that calculation in huge_pmd_unshare
to be VERY ugly and confusing code.

*addr = ALIGN(*addr, HPAGE_SIZE * PTRS_PER_PTE) - HPAGE_SIZE;

Note that it is adjusting the value of passed argument 'unsigned long *addr'.
This argument/value is part of a loop condition in all current callers of
huge_pmd_unshare. For instance:

for (; address < end; address += huge_page_size(h)) {

So, that calculation in huge_pmd_unshare gets the calling loop back to
the starting address of the unmapped range. It even takes the loop increment
'huge_page_size(h)' into account. That is why that ' - HPAGE_SIZE' is at
the end of the calculation.

ugly and confusing! And on my list of things to clean up.
--
Mike Kravetz

\
 
 \ /
  Last update: 2018-08-23 19:02    [W:0.123 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site