[lkml]   [2020]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] mm/hugetlb: Fix calculation of adjust_range_if_pmd_sharing_possible
Hi, Mike,

On Thu, Jul 30, 2020 at 02:49:18PM -0700, Mike Kravetz wrote:
> On 7/30/20 1:16 PM, Peter Xu wrote:
> > This is found by code observation only.
> >
> > Firstly, the worst case scenario should assume the whole range was covered by
> > pmd sharing. The old algorithm might not work as expected for ranges
> > like (1g-2m, 1g+2m), where the adjusted range should be (0, 1g+2m) but the
> > expected range should be (0, 2g).
> >
> > Since at it, remove the loop since it should not be required. With that, the
> > new code should be faster too when the invalidating range is huge.
> Thanks Peter!
> That is certainly much simpler than the loop in current code. You say there
> are instances where old code 'might not work' for ranges like (1g-2m, 1g+2m).
> Not sure I understand what you mean by adjusted and expected ranges in the
> message. Both are possible 'adjusted' ranges depending on vma size.
> Just trying to figure out if there is an actual problem in the existing code
> that needs to be fixed in stable. I think the existing code is correct, just
> inefficient.

Thanks for the quick review!

I'm not sure whether that will cause a real problem, but iiuc in my previous
example of (1g-2m, 1g+2m) in the commit message, the old code will extend the
range to (0, 1g+2m). In this case, if unluckily the (1g, 2g) range is a pud
with shared pmd, then imho we face the risk of partial tlb flushing with the
old code, because it will only flush tlb for range (0, 1g+2m) but not (0, 2g).
If that's the case, maybe it worths cc stable.

Anyway, I'd like to double confirm with you in case I missed something.


Peter Xu

 \ /
  Last update: 2020-07-31 01:28    [W:0.071 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site