On 12/28/20 8:21 PM, Li Xinhai wrote:
> The current code would unnecessarily expand the address range. Consider
> one example, (start, end) = (1G-2M, 3G+2M), and (vm_start, vm_end) =
> (1G-4M, 3G+4M), the expected adjustment should be keep (1G-2M, 3G+2M)
> without expand. But the current result will be (1G-4M, 3G+4M). Actually,
> the range (1G-4M, 1G) and (3G, 3G+4M) would never been involved in pmd
> sharing.
>
> After this patch, if pud aligned *start across vm_start, then we know the
> *start and vm_start are in same pud_index, and vm_start is not pud
> aligned, so don't adjust *start. Same logic applied to *end.
>
> Fixes: commit 75802ca66354 ("mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible")
> Cc: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
> Cc: Peter Xu <peterx@xxxxxxxxxx>
> Signed-off-by: Li Xinhai <lixinhai.lxh@xxxxxxxxx>
Thank you. That does indeed fix an issue in the current code.
Reviewed-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
Andrew,
You asked about user-visible runtime effects. The 'adjusted range' is used
for calls to mmu notifiers and cache(tlb) flushing. Since the current code
unnecessarily expands the range in some cases, more entries than necessary
would be flushed. This would/could result in performance degradation.
However, this is highly dependent on the user runtime. Is there a combination
of vma layout and calls to actually hit this issue? If the issue is hit, will
those entries unnecessarily flushed be used again and need to be unnecessarily
reloaded?
--
Mike Kravetz
