Received: by 2002:ab2:7041:0:b0:1f4:bcc8:f211 with SMTP id x1csp51957lql; Fri, 12 Apr 2024 03:33:16 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVfeugMuEzQaau+wJZDTZbKQtFALGqUVrL3pewEjbmw3KE8MxF6amRPdsRe27lKwJpSGy1aDZDW1cmpGAK2R28CKXPltNpH9HzjK6QoFw== X-Google-Smtp-Source: AGHT+IGz/I3JR68ZuMd9PqaT+jzXYMy/GTx0ZyOXOuuAqUyEQUpeXEHXeXvCrHTq+6w/13ZxHsZW X-Received: by 2002:a05:6a21:164a:b0:1a7:5413:1e6d with SMTP id no10-20020a056a21164a00b001a754131e6dmr7517604pzb.4.1712917995885; Fri, 12 Apr 2024 03:33:15 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712917995; cv=pass; d=google.com; s=arc-20160816; b=ffPxxTjBbSQEtFs0O6FWBHeCbvSpDVds3JE07ZlqMkcWNthiuoI8RniHWOJYxz2TPv nTgCjpIuVl42kVr2Nv5gLyyqfUKZMMZsnltwSQFh+86eekT/N4BLV2wcdSIc1iGGctqw z0R3DxG5Wpik50R9tl5VTTGlUOMQdln1ZOHyQTl7Pqs0gWBYKgGup8NmmqGS3HMDaOZh 25CHukH52lvtpKPm6nQHbimrGTCF5c5Wqv0n+ieDdkeIWVqfjk8sSiZwriuiOg+9Ufer kRo/XHLKk2IPcrQk7blKuR/tVpzPzX+hHh11OPbme21HF7WHhNFWfbOOzmYtdKIKdhtB JM3w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=apOEYbA38biI5zK131qyTNxKhnQALpmBmcBMbCohNBk=; fh=yrszHnBge9iM7HhmvViPuJTTomfyJrXbsPHAr3EObNs=; b=SS9f4MoiG8R5653GpUZGghgyFrSgBnIZCf97a4bt2OJhg6WcbQ5e7m9Hw/9LbIKTN6 p3qhllBMqrF4WwNIzh070OQXJI/2wJhrofWO5qTaOP8YVsKuX+nQjlM82jkhpkf0ula+ y4y5yGrt43VSEm4pe7Apg9nkklPh7SPGrg1yaDog09RCPnsfWaaEQBYSSweHcjLdtfWa KmHa6qiUw25fimngslPX0WkEiT/oz7zKCfo2VjmruqA8ZJalffJ4Z/R9NJI4QpstOv40 Z722A80AzfHKKaIiktiiqY+K/qQWpCLBAEUHsjbs1ODGdilIXRvUwLuCa/36GqIIHQOP H7nw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-142493-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-142493-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id 10-20020a63154a000000b005dc4bdd113fsi2892894pgv.168.2024.04.12.03.33.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 03:33:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-142493-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-142493-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-142493-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id F22D1B2192D for ; Fri, 12 Apr 2024 10:25:43 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6BF9F53E2B; Fri, 12 Apr 2024 10:25:37 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D50B553384 for ; Fri, 12 Apr 2024 10:25:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712917536; cv=none; b=QoZrGyziBzVq9Fs07d4dHBw3qNeVcV+hH2ammJ9biIxJNKv/M9IPtlSwAQFcxtVi1k6Bm9UHQn/SC8XD3I43c/t7mXB4digFDlrRw5TlufEBncnPecS0EszWvCFiJmw7D1331Jk2wB0lksu3qMa+5br8vnpvGzRGslQhNKwVIgo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712917536; c=relaxed/simple; bh=wasIUb5/uQ7Q+XjSsgBnPUXBYRCkQ+aZzrUyKE3vPJs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pWlt3y2QsbPMOQhoi+MmoWETxpAOL2vbKgUrvFiJlsDUmShWbqzM9+JDX1MhUKlysg+3wOiWkH1I9yqTrerlD19jSfjPH6yRr9XasAVPZp7C2wIQovoLBVvgGOmU6tTUyCTPoCe8hiCzKSioNtSPYU6vqVVfZiUurYd4Tcp6zDM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 607EB339; Fri, 12 Apr 2024 03:26:02 -0700 (PDT) Received: from [10.57.73.208] (unknown [10.57.73.208]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 25C9E3F64C; Fri, 12 Apr 2024 03:25:31 -0700 (PDT) Message-ID: <744fc49e-d91b-4f5a-9a27-1a25c50c2154@arm.com> Date: Fri, 12 Apr 2024 11:25:29 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/4] mm: add per-order mTHP anon_fault_alloc and anon_fault_fallback counters Content-Language: en-GB To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, cerasuolodomenico@gmail.com, chrisl@kernel.org, corbet@lwn.net, david@redhat.com, kasong@tencent.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, peterx@redhat.com, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, yosryahmed@google.com, yuzhao@google.com References: <20240412101756.296971-1-21cnbao@gmail.com> From: Ryan Roberts In-Reply-To: <20240412101756.296971-1-21cnbao@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12/04/2024 11:17, Barry Song wrote: > On Fri, Apr 12, 2024 at 9:56 PM Ryan Roberts wrote: >> >> On 12/04/2024 10:43, Barry Song wrote: >>> On Fri, Apr 12, 2024 at 9:27 PM Ryan Roberts wrote: >>>> >>>> Hi Barry, >>>> >>>> 2 remaining comments - otherwise looks good. (same comments I just made in the >>>> v4 conversation). >>>> >>>> On 12/04/2024 08:37, Barry Song wrote: >>>>> From: Barry Song >>>>> >>>>> Profiling a system blindly with mTHP has become challenging due to the >>>>> lack of visibility into its operations.  Presenting the success rate of >>>>> mTHP allocations appears to be pressing need. >>>>> >>>>> Recently, I've been experiencing significant difficulty debugging >>>>> performance improvements and regressions without these figures.  It's >>>>> crucial for us to understand the true effectiveness of mTHP in real-world >>>>> scenarios, especially in systems with fragmented memory. >>>>> >>>>> This patch establishes the framework for per-order mTHP >>>>> counters. It begins by introducing the anon_fault_alloc and >>>>> anon_fault_fallback counters. Additionally, to maintain consistency >>>>> with thp_fault_fallback_charge in /proc/vmstat, this patch also tracks >>>>> anon_fault_fallback_charge when mem_cgroup_charge fails for mTHP. >>>>> Incorporating additional counters should now be straightforward as well. >>>>> >>>>> Signed-off-by: Barry Song >>>>> Cc: Chris Li >>>>> Cc: David Hildenbrand >>>>> Cc: Domenico Cerasuolo >>>>> Cc: Kairui Song >>>>> Cc: Matthew Wilcox (Oracle) >>>>> Cc: Peter Xu >>>>> Cc: Ryan Roberts >>>>> Cc: Suren Baghdasaryan >>>>> Cc: Yosry Ahmed >>>>> Cc: Yu Zhao >>>>> --- >>>>>  include/linux/huge_mm.h | 51 ++++++++++++++++++++++++++++++++++ >>>>>  mm/huge_memory.c        | 61 +++++++++++++++++++++++++++++++++++++++++ >>>>>  mm/memory.c             |  3 ++ >>>>>  mm/page_alloc.c         |  4 +++ >>>>>  4 files changed, 119 insertions(+) >>>>> >>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >>>>> index e896ca4760f6..c5beb54b97cb 100644 >>>>> --- a/include/linux/huge_mm.h >>>>> +++ b/include/linux/huge_mm.h >>>>> @@ -264,6 +264,57 @@ unsigned long thp_vma_allowable_orders(struct vm_area_struct *vma, >>>>>                                         enforce_sysfs, orders); >>>>>  } >>>>> >>>>> +enum mthp_stat_item { >>>>> +     MTHP_STAT_ANON_FAULT_ALLOC, >>>>> +     MTHP_STAT_ANON_FAULT_FALLBACK, >>>>> +     MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE, >>>>> +     __MTHP_STAT_COUNT >>>>> +}; >>>>> + >>>>> +struct mthp_stat { >>>>> +     unsigned long stats[0][__MTHP_STAT_COUNT]; >>>>> +}; >>>>> + >>>>> +extern struct mthp_stat __percpu *mthp_stats; >>>>> + >>>>> +static inline void count_mthp_stat(int order, enum mthp_stat_item item) >>>>> +{ >>>>> +     if (order <= 0 || order > PMD_ORDER || !mthp_stats) >>>>> +             return; >>>>> + >>>>> +     this_cpu_inc(mthp_stats->stats[order][item]); >>>>> +} >>>>> + >>>>> +static inline void count_mthp_stats(int order, enum mthp_stat_item item, long delta) >>>>> +{ >>>>> +     if (order <= 0 || order > PMD_ORDER || !mthp_stats) >>>>> +             return; >>>>> + >>>>> +     this_cpu_add(mthp_stats->stats[order][item], delta); >>>>> +} >>>>> + >>>>> +/* >>>>> + * Fold the foreign cpu mthp stats into our own. >>>>> + * >>>>> + * This is adding to the stats on one processor >>>>> + * but keeps the global counts constant. >>>>> + */ >>>>> +static inline void mthp_stats_fold_cpu(int cpu) >>>>> +{ >>>>> +     struct mthp_stat *fold_stat; >>>>> +     int i, j; >>>>> + >>>>> +     if (!mthp_stats) >>>>> +             return; >>>>> +     fold_stat = per_cpu_ptr(mthp_stats, cpu); >>>>> +     for (i = 1; i <= PMD_ORDER; i++) { >>>>> +             for (j = 0; j < __MTHP_STAT_COUNT; j++) { >>>>> +                     count_mthp_stats(i, j, fold_stat->stats[i][j]); >>>>> +                     fold_stat->stats[i][j] = 0; >>>>> +             } >>>>> +     } >>>>> +} >>>> >>>> This is a pretty horrible hack; I'm pretty sure just summing for all *possible* >>>> cpus should work. >>>> >>>>> + >>>>>  #define transparent_hugepage_use_zero_page()                         \ >>>>>       (transparent_hugepage_flags &                                   \ >>>>>        (1<>>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>>>> index dc30139590e6..21c4ac74b484 100644 >>>>> --- a/mm/huge_memory.c >>>>> +++ b/mm/huge_memory.c >>>>> @@ -526,6 +526,50 @@ static const struct kobj_type thpsize_ktype = { >>>>>       .sysfs_ops = &kobj_sysfs_ops, >>>>>  }; >>>>> >>>>> +struct mthp_stat __percpu *mthp_stats; >>>>> + >>>>> +static unsigned long sum_mthp_stat(int order, enum mthp_stat_item item) >>>>> +{ >>>>> +     unsigned long sum = 0; >>>>> +     int cpu; >>>>> + >>>>> +     cpus_read_lock(); >>>>> +     for_each_online_cpu(cpu) { >>>>> +             struct mthp_stat *this = per_cpu_ptr(mthp_stats, cpu); >>>>> + >>>>> +             sum += this->stats[order][item]; >>>>> +     } >>>>> +     cpus_read_unlock(); >>>>> + >>>>> +     return sum; >>>>> +} >>>>> + >>>>> +#define DEFINE_MTHP_STAT_ATTR(_name, _index)                                 \ >>>>> +static ssize_t _name##_show(struct kobject *kobj,                    \ >>>>> +                     struct kobj_attribute *attr, char *buf)         \ >>>>> +{                                                                    \ >>>>> +     int order = to_thpsize(kobj)->order;                            \ >>>>> +                                                                     \ >>>>> +     return sysfs_emit(buf, "%lu\n", sum_mthp_stat(order, _index));  \ >>>>> +}                                                                    \ >>>>> +static struct kobj_attribute _name##_attr = __ATTR_RO(_name) >>>>> + >>>>> +DEFINE_MTHP_STAT_ATTR(anon_fault_alloc, MTHP_STAT_ANON_FAULT_ALLOC); >>>>> +DEFINE_MTHP_STAT_ATTR(anon_fault_fallback, MTHP_STAT_ANON_FAULT_FALLBACK); >>>>> +DEFINE_MTHP_STAT_ATTR(anon_fault_fallback_charge, MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE); >>>>> + >>>>> +static struct attribute *stats_attrs[] = { >>>>> +     &anon_fault_alloc_attr.attr, >>>>> +     &anon_fault_fallback_attr.attr, >>>>> +     &anon_fault_fallback_charge_attr.attr, >>>>> +     NULL, >>>>> +}; >>>>> + >>>>> +static struct attribute_group stats_attr_group = { >>>>> +     .name = "stats", >>>>> +     .attrs = stats_attrs, >>>>> +}; >>>>> + >>>>>  static struct thpsize *thpsize_create(int order, struct kobject *parent) >>>>>  { >>>>>       unsigned long size = (PAGE_SIZE << order) / SZ_1K; >>>>> @@ -549,6 +593,12 @@ static struct thpsize *thpsize_create(int order, struct kobject *parent) >>>>>               return ERR_PTR(ret); >>>>>       } >>>>> >>>>> +     ret = sysfs_create_group(&thpsize->kobj, &stats_attr_group); >>>>> +     if (ret) { >>>>> +             kobject_put(&thpsize->kobj); >>>>> +             return ERR_PTR(ret); >>>>> +     } >>>>> + >>>>>       thpsize->order = order; >>>>>       return thpsize; >>>>>  } >>>>> @@ -691,6 +741,11 @@ static int __init hugepage_init(void) >>>>>        */ >>>>>       MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER < 2); >>>>> >>>>> +     mthp_stats = __alloc_percpu((PMD_ORDER + 1) * sizeof(mthp_stats->stats[0]), >>>>> +                     sizeof(unsigned long)); >>>> >>>> Personally I think it would be cleaner to allocate statically using >>>> ilog2(MAX_PTRS_PER_PTE) instead of PMD_ORDER. >>> >>> Hi Ryan, >>> >>> I don't understand why MAX_PTRS_PER_PTE is the correct size. For ARM64, >>> >>> #define PMD_ORDER       (PMD_SHIFT - PAGE_SHIFT) >>> >>> #define MAX_PTRS_PER_PTE PTRS_PER_PTE >>> >>> #define PTRS_PER_PTE            (1 << (PAGE_SHIFT - 3)) >>> >>> while PAGE_SIZE is 16KiB or 64KiB, PTRS_PER_PTE can be a huge number? >>> >>> >>> Am I missing something? >> >> PTRS_PER_PTE is the number of PTE entries in a PTE table. On arm64 its as follows: >> >> PAGE_SIZE       PAGE_SHIFT      PTRS_PER_PTE >> 4K              12              512 >> 16K             14              2048 >> 64K             16              8192 >> >> So (PTRS_PER_PTE * PAGE_SIZE) = PMD_SIZE >> >> PMD_ORDER is ilog2(PMD_SIZE / PAGE_SIZE) = ilog2(PTRS_PER_PTE) >> >> MAX_PTRS_PER_PTE is just the maximum value that PTRS_PER_PTE will ever have, >> (and its equal to PTRS_PER_PTE except for powerpc). >> >> Pretty sure the math is correct? > > I am not convinced the math is correct :-) > > while page size is 64KiB, the page table is as below, > PMD_ORDER = L2 index bits = [41:29] = 13 != ilog2(8192) 1 << 13 = 8192 Right? So: ilog2(8192) = 13 What's wrong with that? I even checked in Python to make sure I'm not going mad: >>> import math >>> math.log2(8192) 13.0 > > > +--------+--------+--------+--------+--------+--------+--------+--------+ > |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| > +--------+--------+--------+--------+--------+--------+--------+--------+ > | | | | | > | | | | v > | | | | [15:0] in-page offset > | | | +----------> [28:16] L3 index > | | +--------------------------> [41:29] L2 index > | +-------------------------------> [47:42] L1 index (48-bit) > | [51:42] L1 index (52-bit) > +-------------------------------------------------> [63] TTBR0/1 > > while page size is 4KiB, the page table is as below, > > +--------+--------+--------+--------+--------+--------+--------+--------+ > |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| > +--------+--------+--------+--------+--------+--------+--------+--------+ > | | | | | | > | | | | | v > | | | | | [11:0] in-page offset > | | | | +-> [20:12] L3 index > | | | +-----------> [29:21] L2 index > | | +---------------------> [38:30] L1 index > | +-------------------------------> [47:39] L0 index > +-------------------------------------------------> [63] TTBR0/1 > > PMD_ORDER = L2 index bits = [29:21] = 9 = ilog2(512). > > You are only correct while page size = 4KiB. > > > >