On Mon 05-10-20 07:59:12, Anshuman Khandual wrote: > > > On 10/02/2020 05:34 PM, Michal Hocko wrote: > > On Wed 30-09-20 11:30:49, 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. > > What is the actual usecase? And how do you deal with the complexity > > introduced by many different hugetlb page sizes. Really, what is the > > point to having such a detailed view on hugetlb migration? > > > > It helps differentiate various page migration events i.e normal, THP and > HugeTLB and gives us more reliable and accurate measurement. Current stats > as per PGMIGRATE_SUCCESS and PGMIGRATE_FAIL are misleading, as they contain > both normal and HugeTLB pages as single entities, which is not accurate. Yes this is true. But why does it really matter? Do you have a specific example? > After this change, PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will contain page > migration statistics in terms of normal pages irrespective of whether any > previous migrations until that point involved normal pages, THP or HugeTLB > (any size) pages. At the least, this fixes existing misleading stats with > PGMIGRATE_SUCCESS and PGMIGRATE_FAIL. > > Besides, it helps us understand HugeTLB migrations in more detail. Even > though HugeTLB can be of various sizes on a given platform, these new > stats HUGETLB_MIGRATION_SUCCESS and HUGETLB_MIGRATION_FAILURE give enough > overall insight into HugeTLB migration events. While true this all is way too vague to add yet another imprecise counter. -- Michal Hocko SUSE Labs
