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=-8.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 4DD1BC2D0A8 for ; Mon, 28 Sep 2020 03:33:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 94841239A1 for ; Mon, 28 Sep 2020 03:33:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94841239A1 Authentication-Results: mail.kernel.org; dmarc=none (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 ACF8B6B005D; Sun, 27 Sep 2020 23:33:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A827F8E0001; Sun, 27 Sep 2020 23:33:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BE3F6B0068; Sun, 27 Sep 2020 23:33:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id 861CA6B005D for ; Sun, 27 Sep 2020 23:33:09 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 39B49181AE865 for ; Mon, 28 Sep 2020 03:33:09 +0000 (UTC) X-FDA: 77311049298.23.apple91_5f08cf52717e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 1590E37606 for ; Mon, 28 Sep 2020 03:33:09 +0000 (UTC) X-HE-Tag: apple91_5f08cf52717e X-Filterd-Recvd-Size: 3847 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Mon, 28 Sep 2020 03:33:08 +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 994FB101E; Sun, 27 Sep 2020 20:33:07 -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 DB8DA3F6CF; Sun, 27 Sep 2020 20:33:04 -0700 (PDT) From: Anshuman Khandual Subject: Re: [RFC] mm/vmstat: Add events for HugeTLB migration To: Oscar Salvador Cc: linux-mm@kvack.org, Daniel Jordan , Zi Yan , John Hubbard , Mike Kravetz , Andrew Morton , linux-kernel@vger.kernel.org References: <1601025149-13311-1-git-send-email-anshuman.khandual@arm.com> <20200925094912.GA31664@linux> Message-ID: Date: Mon, 28 Sep 2020 09:02:23 +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: <20200925094912.GA31664@linux> 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 09/25/2020 03:19 PM, Oscar Salvador wrote: > 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 >> Cc: Zi Yan >> Cc: John Hubbard >> Cc: Mike Kravetz >> Cc: Andrew Morton >> Cc: linux-mm@kvack.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual > > Was this inspired by some usecase/debugging or just to follow THP's example? Currently HugeTLB migration events get accommodated in PGMIGRATE_SUCCESS and PGMIGRATE_FAIL event stats as normal single page instances. Previously this might have just seemed okay as HugeTLB page could be viewed as a single page entity, even though it was not fully accurate as PGMIGRATE_[SUCCESS|FAILURE] tracked statistics in terms of normal base pages. But tracking HugeTLB pages as single pages does not make sense any more, now that THP pages are accounted for properly. This would complete the revamped page migration accounting where PGMIGRATE_[SUCCESS|FAILURE] will track entire page migration events in terms of normal base pages and THP_*/HUGETLB_* will track specialized events when applicable. > >> 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? > Right, will fix it.