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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 565E9C41604 for ; Tue, 6 Oct 2020 07:54:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A9F3220760 for ; Tue, 6 Oct 2020 07:54:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="E+vaR6Uk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9F3220760 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C16266B005C; Tue, 6 Oct 2020 03:54:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC6716B005D; Tue, 6 Oct 2020 03:54:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB64F6B0062; Tue, 6 Oct 2020 03:54:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0247.hostedemail.com [216.40.44.247]) by kanga.kvack.org (Postfix) with ESMTP id 7AD146B005C for ; Tue, 6 Oct 2020 03:54:35 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0DDE4180AD801 for ; Tue, 6 Oct 2020 07:54:35 +0000 (UTC) X-FDA: 77340738510.20.car37_280a91d271c5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id DC9CF180C07A3 for ; Tue, 6 Oct 2020 07:54:34 +0000 (UTC) X-HE-Tag: car37_280a91d271c5 X-Filterd-Recvd-Size: 5404 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Tue, 6 Oct 2020 07:54:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1601970873; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PtL/QE9wTchzRfp7x1He5ORldnbI5Ri9Nvy/1IWwkW0=; b=E+vaR6Uk6ou43BGiPTnRmllcl6ZWccsMtaAPvz5CeW+lucWVz4zFAsHFKL5FUdYTKBV+eY ZOlZO/Zw7fu6+f1OUw0WC3v/m/qC1yaAYAem2zkMyumm7lULDZyuVLFdnW1zCNFCmXtL6w tNMBqIGJmoA4wKO+F1774VW8T1ZA91U= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0D0E9ADBB; Tue, 6 Oct 2020 07:54:33 +0000 (UTC) Date: Tue, 6 Oct 2020 09:54:32 +0200 From: Michal Hocko To: Anshuman Khandual Cc: linux-mm@kvack.org, Daniel Jordan , Zi Yan , John Hubbard , Mike Kravetz , Oscar Salvador , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [RFC V2] mm/vmstat: Add events for HugeTLB migration Message-ID: <20201006075432.GA29020@dhcp22.suse.cz> References: <1601445649-22163-1-git-send-email-anshuman.khandual@arm.com> <20201002120422.GE4555@dhcp22.suse.cz> <20201005060542.GM4555@dhcp22.suse.cz> <308767be-acb3-a170-e64f-3c64a361f26e@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <308767be-acb3-a170-e64f-3c64a361f26e@arm.com> 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 Tue 06-10-20 08:26:35, Anshuman Khandual wrote: > > > On 10/05/2020 11:35 AM, Michal Hocko wrote: > > 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? > > An example which demonstrates that mixing and misrepresentation in these > stats create some problem ? Well, we could just create one scenario via > an application with different VMA types and triggering some migrations. > But the fact remains, that these stats are inaccurate and misleading > which is very clear and apparent. This doesn't sound like a proper justification to me. > >> 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. > > Given that user knows about all HugeTLB mappings it has got, these counters > are not really vague and could easily be related back. How can you tell a difference between different hugetlb sizes? > Moreover this change > completes the migration stats restructuring which was started with adding > THP counters. Otherwise it remains incomplete. Our counters will be always incomplete. Please do realize they are mere aid rather than a comprihensive toolset to identify the system behavior to the very detail. We have way too many counters and this particular ones are not adding much IMHO. At least not from your description which sounds to me like "Yeah, why not do that although there is no strong reason, well except that THP already has it so let's do it for hugetlb as well". I really do not want to deal with yet another report in few years that somebody wants to distinguish hugetlb migration of different sizes. Really, is there any _real_ practical use for these other than "nice, let's just have it"? -- Michal Hocko SUSE Labs