Re: [PATCH v2] mm/hugetlb: Fix calculation of adjust_range_if_pmd_sharing_possible

From: Mike Kravetz <mike.kravetz@oracle.com>
To: Peter Xu <peterx@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v2] mm/hugetlb: Fix calculation of adjust_range_if_pmd_sharing_possible
Date: Thu, 30 Jul 2020 14:49:18 -0700	[thread overview]
Message-ID: <4680014a-a328-b0c2-dc86-8c1eb4556f69@oracle.com> (raw)
In-Reply-To: <20200730201636.74778-1-peterx@redhat.com>

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.
-- 
Mike Kravetz