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
