From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DF4CC4363C for ; Mon, 5 Oct 2020 02:30:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C11D22078E for ; Mon, 5 Oct 2020 02:30:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C11D22078E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CEEF58E0001; Sun, 4 Oct 2020 22:30:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9F766B0062; Sun, 4 Oct 2020 22:30:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB4ED8E0001; Sun, 4 Oct 2020 22:30:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id 8CF986B005D for ; Sun, 4 Oct 2020 22:30:04 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 151073631 for ; Mon, 5 Oct 2020 02:30:04 +0000 (UTC) X-FDA: 77336291928.23.swim18_3d11311271ba Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id DEF7537606 for ; Mon, 5 Oct 2020 02:30:03 +0000 (UTC) X-HE-Tag: swim18_3d11311271ba X-Filterd-Recvd-Size: 3378 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Mon, 5 Oct 2020 02:30:03 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2FDFA101E; Sun, 4 Oct 2020 19:30:02 -0700 (PDT) Received: from [192.168.0.130] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EA9223F71F; Sun, 4 Oct 2020 19:29:58 -0700 (PDT) From: Anshuman Khandual Subject: Re: [RFC V2] mm/vmstat: Add events for HugeTLB migration To: Michal Hocko Cc: linux-mm@kvack.org, Daniel Jordan , Zi Yan , John Hubbard , Mike Kravetz , Oscar Salvador , Andrew Morton , linux-kernel@vger.kernel.org References: <1601445649-22163-1-git-send-email-anshuman.khandual@arm.com> <20201002120422.GE4555@dhcp22.suse.cz> Message-ID: Date: Mon, 5 Oct 2020 07:59:12 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20201002120422.GE4555@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. 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. Though these new stats accumulate HugeTLB migration success and failure irrespective of their size, it will still be helpful as HugeTLB is user driven, who should be able to decipher these accumulated stats. But this is a limitation, as it might be difficult to determine available HugeTLB sizes at compile time.