Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp993200ybg; Mon, 1 Jun 2020 21:25:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOom25XwW8wP/CVFK7lA5tbZC1Q8yvxTgd3j+DwJw4hIjA2hpMoKpmQ7hYWr5ZAb+7L/c4 X-Received: by 2002:a17:906:799:: with SMTP id l25mr11205687ejc.234.1591071954933; Mon, 01 Jun 2020 21:25:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591071954; cv=none; d=google.com; s=arc-20160816; b=ZclDR0bMRB+p6x1r9Ezuh5toL5h4fO+KGefRQ+IHkcPFSp9jY0rhxBrwsP5pgV5mu+ mWVg0bqqe6ZrjGJMS3yeX+5SgSUpTS8VLOHPTeLMEVqQZl/4YJ28PAjMcgFEMuWG5+zg AkSmhthaEtKJHwBbJRehmoL/znYhfbVxvfOH5NBE9ib/L3ikdgeVFSu93bLjOb2yZFSD bcWZzpjm2CkOrK4urZUn0OZ1FkrgZT0gIQKAGg5sFcLTbWLzvXznGUCvYdWr+TDs31Kd +cSWKhPF61sCQUyKxykix3GtNGKyYU4D6MeoSUdjQfHkVuFF+eV1/IpOxtQL4aj65FtL UE7Q== 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=PAcjiUyXS7U14FHZYqZGiHyL3UfFTIR+T6AvZWMmVRk=; b=Hdfett3atUgnwH+qqWsTFpWJdt0JHCqKpY8fZ04xQCl0H19Sso6Dz0IbW+8IPK919X rRlAO4OGx2BX2iblCEFGEdUO7gW9c5wTxVtt0zHvn+6ZLC74cd4TuRJi8SHLPxcsCQEq aotJ/panq5X3bv6ZWA0cTHwd61lyReWTPJDunPCdSkn9pwyOmot8EK4uL1Q1fL+GSqm8 Aao8iagJ3npEtA2vPP9MbLisP2RAOXFL/v2+ugYtOF6GyltQQ0x7fCQwhla/5Nh5UC1u Ws+Z/NmrEJ3XkSCAZw4DznCKU60FaFrsxxN5nhIg96EEKc4D7U+UiIKdwyYKScNDy1kK T8GA== 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 24si810619ejy.536.2020.06.01.21.25.32; Mon, 01 Jun 2020 21:25:54 -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 S1726032AbgFBEVf (ORCPT + 99 others); Tue, 2 Jun 2020 00:21:35 -0400 Received: from foss.arm.com ([217.140.110.172]:45920 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725616AbgFBEVf (ORCPT ); Tue, 2 Jun 2020 00:21: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 5BEC055D; Mon, 1 Jun 2020 21:21:34 -0700 (PDT) Received: from [192.168.0.129] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8C92D3F52E; Mon, 1 Jun 2020 21:21:31 -0700 (PDT) Subject: Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split To: John Hubbard , Daniel Jordan 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> From: Anshuman Khandual Message-ID: <1e71d815-5359-3ebe-5d2b-5a3b54b63b51@arm.com> Date: Tue, 2 Jun 2020 09:50:29 +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: <0a936ec7-f44f-1d72-915f-f5758d25fd72@nvidia.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:50 AM, John Hubbard wrote: > On 2020-06-01 09:57, Daniel Jordan wrote: >> Hi Anshuman, >> >> On Fri, May 22, 2020 at 09:04:04AM +0530, Anshuman Khandual wrote: >>> This adds the following two new VM events which will help in validating PMD >>> based THP migration without split. Statistics reported through these events >>> will help in performance debugging. >>> >>> 1. THP_PMD_MIGRATION_SUCCESS >>> 2. THP_PMD_MIGRATION_FAILURE >> >> The names suggest a binary event similar to the existing >> pgmigrate_success/fail, but FAILURE only tracks one kind of migration error, >> and then only when the thp is successfully split, so shouldn't it be called >> SPLIT instead? >> > > So the full description of the situation, which we're trying to compress into > a shorter name, is "THP pmd migration failure, due to successfully splitting > the THP". From that, the beginning part is the real point here, while the last > part is less important. In other words, the users of these events are people > who are trying to quantify THP migrations, and these events are particularly > relevant for that. The "THP migration failed" is more important here than > the reason that it failed. Or so I believe so far. Absolutely, these events really help in quantifying THP migration successes or their failures that involve splitting. > > So I still think that the names are really quite good, but your point is Agreed. > also important: maybe this patch should also be tracking other causes > of THP PMD migration failure, in order to get a truer accounting of the > situation. Is there any other failure reasons which are only specific to THP migration. Else, adding stats about generic migration failure reasons will just blur the overall understanding about THP migration successes and failure cases that results in splitting.