On 2/3/21 2:53 PM, Jason Gunthorpe wrote:
> On Wed, Feb 03, 2021 at 01:22:18PM +0000, Joao Martins wrote:
>
>> With this, longterm gup will 'regress' for hugetlbfs e.g. from ~6k -> ~32k
>> usecs when
>> pinning a 16G hugetlb file.
>
> Yes, but correctness demands it.
>
Hence the quotes around the word regress.
But still, we are adding unnecessary overhead (previously nonexistent) to
compound pages
even those where the issue doesn't exist (hugetlb).
> The solution is to track these pages as we discover them so we know if
> a PMD/PUD points and can directly skip the duplicated work
>
That looks better. It would require moving check_and_migrate_movable_pages()
elsewhere,
and/or possibly reworking the entire series?
>> Splitting can only occur on THP right? If so, perhaps we could
>> retain the @step increment for compound pages but when
>> !is_transparent_hugepage(head) or just PageHuge(head) like:
>
> Honestly I'd rather see it fixed properly which will give even bigger
> performance gains - avoiding the entire rescan of the page list will
> be a win
>
If check_and_migrate_movable_pages() is meant to migrate unpinned pages, then
rather than
pinning+unpinning+moving, perhaps it would be called in __get_user_pages()
place where we
are walking page tables and know if it's a PUD/PMD and can skip all the
subpages and just
record and migrate those instead. Was that your thinking?
Joao
