On Fri, Sep 25, 2020 at 02:42:29PM +0530, Anshuman Khandual wrote:
> Add following new vmstat events which will track HugeTLB page migration.
>
> 1. HUGETLB_MIGRATION_SUCCESS
> 2. HUGETLB_MIGRATION_FAILURE
>
> It follows the existing semantics to accommodate HugeTLB subpages in total
> page migration statistics. While here, this updates current trace event
> "mm_migrate_pages" to accommodate now available HugeTLB based statistics.
>
> Cc: Daniel Jordan <daniel.m.jor...@oracle.com>
> Cc: Zi Yan <z...@nvidia.com>
> Cc: John Hubbard <jhubb...@nvidia.com>
> Cc: Mike Kravetz <mike.krav...@oracle.com>
> Cc: Andrew Morton <a...@linux-foundation.org>
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khand...@arm.com>
Was this inspired by some usecase/debugging or just to follow THP's example?
> int retry = 1;
> int thp_retry = 1;
> + int hugetlb_retry = 1;
> int nr_failed = 0;
> int nr_succeeded = 0;
> int nr_thp_succeeded = 0;
> int nr_thp_failed = 0;
> int nr_thp_split = 0;
> + int nr_hugetlb_succeeded = 0;
> + int nr_hugetlb_failed = 0;
> int pass = 0;
> bool is_thp = false;
> + bool is_hugetlb = false;
> struct page *page;
> struct page *page2;
> int swapwrite = current->flags & PF_SWAPWRITE;
> @@ -1433,6 +1437,7 @@ int migrate_pages(struct list_head *from, new_page_t
> get_new_page,
> for (pass = 0; pass < 10 && (retry || thp_retry); pass++) {
Should you not have put hugetlb_retry within the loop as well?
Otherwise we might not rety for hugetlb pages now?
--
Oscar Salvador
SUSE L3
