Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp208266ybg; Tue, 2 Jun 2020 21:43:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx9PzEdpMWUJXJ7ZC5q8B4ea28QoW5IK9gQ6oFVbfANXPignStiGMI3gjc7jyg9vHlr9Q8V X-Received: by 2002:a17:906:3c8:: with SMTP id c8mr4427419eja.129.1591159407226; Tue, 02 Jun 2020 21:43:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591159407; cv=none; d=google.com; s=arc-20160816; b=a8B05LaZVEpSP9pbQm85UIiTsK06YmWe56kMo7bCSdg1Adt9LQVfp+GtNGfC8p5P+g h1/Jj97PTFm59nBbJ++e2xgdqf0IAr3FAp/U9SohpLHsxmWF84NuBp5m/MLcWRvSRO+8 LeKBuvb8CdOKvLHKDrXxaKx/LSmSpVW1bocjbd2Ek2TlPswn4O7AFeVP6HpncOiR2re+ SADFJOyUJIRxxSIW1bTZFt6aL6R3tOpuPwWMe+GpiDdmSNbzDEq21C26AazJJfksr7tD NmrT8vmzO+OQQqF8/T/gXeNZ5qFFxxZ4C9X0PxlC3dK/tbLaT2OTu6cnaE1xggaOGBF2 UlLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=WdP6Yx97gdMCbFVFqx1baUcxnft0IlatdFpCZPjKHT0=; b=r/2GGfJFPn7TtKSj6zH4pyoGP7itb2AdTPbhkOZLvmqhxWGnICS5I0RM5pedSDfX1y pKfd4BIVxF82qQ52Z7VQszNHx0yIc6exbfai8rahIXEvsn1Swi4GiPG+Kr5uXWgSNedQ SQIybONnCAnD0+ZnXBwNoVLl4Y56jT8GzeeeOIFe19AL/9D2wBrOFuWjDbcwhHoDXVu7 rDt1TiMAMZ8Rtpkr+mfu9qT3xe4RCLMDp2Ye+zjGfs5DqEdH2QlGUMHsLryvTSvrbYKD IiN5WKulq/urLcEWhLfr8OZXHgHu0DiRsp9sLPv+393cPa2PHqds6UQpyizoo0PcnMcU O6tQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id fx20si547219ejb.50.2020.06.02.21.42.50; Tue, 02 Jun 2020 21:43:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725936AbgFCEhf (ORCPT + 99 others); Wed, 3 Jun 2020 00:37:35 -0400 Received: from foss.arm.com ([217.140.110.172]:57058 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725275AbgFCEhf (ORCPT ); Wed, 3 Jun 2020 00:37:35 -0400 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 B630231B; Tue, 2 Jun 2020 21:37:34 -0700 (PDT) Received: from [10.163.77.218] (unknown [10.163.77.218]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E92843F305; Tue, 2 Jun 2020 21:37:31 -0700 (PDT) Subject: Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split To: Daniel Jordan , John Hubbard Cc: linux-mm@kvack.org, hughd@google.com, Naoya Horiguchi , Zi Yan , Andrew Morton , linux-kernel@vger.kernel.org References: <1590118444-21601-1-git-send-email-anshuman.khandual@arm.com> <20200601165736.qw5kwwknxltk7bv6@ca-dmjordan1.us.oracle.com> <0a936ec7-f44f-1d72-915f-f5758d25fd72@nvidia.com> <1e71d815-5359-3ebe-5d2b-5a3b54b63b51@arm.com> <274be3bf-2206-5e98-8114-1d91fac472c9@nvidia.com> <20200602145208.qucum52lwslhiqff@ca-dmjordan1.us.oracle.com> From: Anshuman Khandual Message-ID: Date: Wed, 3 Jun 2020 10:06:31 +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: <20200602145208.qucum52lwslhiqff@ca-dmjordan1.us.oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/02/2020 08:22 PM, Daniel Jordan wrote: > On Mon, Jun 01, 2020 at 09:48:09PM -0700, John Hubbard wrote: >> However, the fact that this is under discussion hints at the need for a >> bit of documentation help. What do you think about adding some notes about >> all of this to, say, Documentation/vm/page_migration.rst ? > > Yes, that would be good. I understand the intent better now but still think > the 'failure' event could be misinterpreted as outright failure instead of > splitting followed by successfully moving the constituent pages. Does this look okay and sufficient ? --- a/Documentation/vm/page_migration.rst +++ b/Documentation/vm/page_migration.rst @@ -253,5 +253,20 @@ which are function pointers of struct address_space_operations. PG_isolated is alias with PG_reclaim flag so driver shouldn't use the flag for own purpose. +Quantifying Migration +===================== +Following events can be used to quantify page migration. + +- PGMIGRATE_SUCCESS +- PGMIGRATE_FAIL +- THP_MIGRATION_SUCCESS +- THP_MIGRATION_FAILURE + +THP_MIGRATION_FAILURE in particular represents an event when a THP could not be +migrated as a single entity following an allocation failure and ended up getting +split into constituent normal pages before being retried. This event, along with +PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will help in quantifying and analyzing THP +migration events including both success and failure cases. + > > It might help to clarify in the changelog as well. > Sure, will update the commit message accordingly.