Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <747deb43-68c8-449f-b41a-91864820a699@intel.com>
Date:   Thu, 31 Aug 2023 16:02:59 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/5] mm: LARGE_ANON_FOLIO for improved performance
Content-Language: en-US
To:     David Hildenbrand <david@redhat.com>,
        "Huang, Ying" <ying.huang@intel.com>,
        Ryan Roberts <ryan.roberts@arm.com>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        Matthew Wilcox <willy@infradead.org>,
        Yu Zhao <yuzhao@google.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Yang Shi <shy828301@gmail.com>, Zi Yan <ziy@nvidia.com>,
        Luis Chamberlain <mcgrof@kernel.org>,
        Itaru Kitayama <itaru.kitayama@gmail.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>
References: <20230810142942.3169679-1-ryan.roberts@arm.com>
 <20230810142942.3169679-4-ryan.roberts@arm.com>
 <87v8dg6lfu.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <5c9ba378-2920-4892-bdf0-174e47d528b7@arm.com>
 <87cyz43s63.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <4e14730b-4e4c-de30-04bb-9f3ec4a93754@redhat.com>
From:   "Yin, Fengwei" <fengwei.yin@intel.com>
In-Reply-To: <4e14730b-4e4c-de30-04bb-9f3ec4a93754@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NW9UQXFhUkJwek9ab0JiVy81UHcvb2pJbGthL0s2UFl0a1JpczBTYUdZME1S?=
 =?utf-8?B?d2VRZENKQnFHeHQvL3RVVlFmVHcvWXBXZEpCRUFVQzVKVEJ6SFd4OVFJU2hh?=
 =?utf-8?B?aXNXdVBUelFRWkVZTkFzbFNWSkR6R2N2ZkxXNzE4UFduMWRMeXBBaFVVRjlH?=
 =?utf-8?B?cjd1VU50eWgwZ3NNQ3lXTWtadGhHaUVLeHA1Y3cwb0lSY0lyRStJWmRMaXNY?=
 =?utf-8?B?cGhhU2RQekg2dU5Uc3ZVS2dsdDF5QytpSmYvMGd5L3I5dEhpNWcvQlZLZ3o3?=
 =?utf-8?B?VGpnZ3JuYjRnaGdXN1E2clhoWkF6c3ZhL1N0UndiWEt4YlVFL0JnZEhTTExa?=
 =?utf-8?B?WnRQY3BLaVFJK3ZaZzloWFlzWW1sY2t3NDg5Y1lBYkduc1EycE11YVFWVVB4?=
 =?utf-8?B?YXBUdnYwaFU2QW1HdE9jQm9oMjhTYk01R0pjNlQvNFBadWc3S3hXK1IxRnJX?=
 =?utf-8?B?ZFN3dGJsZW9hcXRrLzUzSm1NejVyeWp0bHp5b0dWTTBLd0hwY2J2ekdJTFF3?=
 =?utf-8?B?Q21tdHJiUGljemJ4SGFFSzZlMHBoVnAvWTZCVVYwTTRLRURrcTkwcllXYndB?=
 =?utf-8?B?d2ovVUZHMUdHYVkwZm03TmIvanQvVmE2aEZ4cEhyVzFBbXA3cEJ2WHdxSVFQ?=
 =?utf-8?B?eHVYdTdNamMyTGh1amx0YmgrOFdycVAwb250Q3ZrQ2ZOaS9KaSt3WTUyejlY?=
 =?utf-8?B?bnJMNFFPY2lBSWJZNSs1RmNrdmJwODhaUFowV3U2VUtrZllqRHpHVVdJMEg1?=
 =?utf-8?B?S0IvVDRmbS9hbHJDWUF3QWE2dVlhNUlLZldKYjFUV2dRclpkL2pzRkJvaHhR?=
 =?utf-8?B?SS9lTkcwWlJtZjhlWFZ4Y3VsMHlwNnpaeHhBcTg3L2JFVHhZWUJoOFVwU3J0?=
 =?utf-8?B?eUhWc21uNWd0a3BpTWpZb2NmbUM5b3lzcm9SR1FUZjJhc1Nnc3BlNXB5SVAy?=
 =?utf-8?B?RTdjTFRsOFJ3VzVoZDUrdE9ubzZ5SU54MmZnazNPaTdmS1k4NjN5cmY0NWlj?=
 =?utf-8?B?S1Zrc2d3YjNVN0tCVmtxajhTeE5jRW9adFpSQ2xKQ1pKWDIwL1NUUUZPWFh2?=
 =?utf-8?B?SGlUWjVudEorRVRPMVIzNjMwVllzUzdCa2tZMXVpcXNxUmVvQzNHN1NMOG53?=
 =?utf-8?B?WkY3ak9peTN3WklwRHpDQ0hJRGVjdDQwaXJtZ0dWV05wYUdlbmRmM1FodTFp?=
 =?utf-8?B?cG9YUjBOdWNCUlBWdkllaTlnZ0tBQUl6MG5iakxpWFg0dGVwY3hPQTNkTDhO?=
 =?utf-8?B?d05pbkhHTFZ6RFB0c0xnWFJTU3Z0YWhqWVNkYytwTEpRbjdXdFFFWEtTdWxF?=
 =?utf-8?B?V0FTR1lYRW5rcU80L2VYWC93UGZPZHpUY3ViRUQxdy90U2NmZU52N3JWbXhn?=
 =?utf-8?B?VTBYMDhSYUZzejFLcUsvMTBwMkMrNXJkdjNlUlJoTkg2VWZKQVYzNFlmQ014?=
 =?utf-8?B?amNtQjIyVkptUVE2dnhVNUdtYjF2WkdJNGEyUVovTWVLcWthbi9FWmROZ2lD?=
 =?utf-8?B?Z0lZaGxxL2oxZjlhRzEwM291V29pbXlUMTJ6Y0ZQT1JZbG5rL3BqdGhRZldu?=
 =?utf-8?B?eUpobStOZ0wrOW9zU3RocGNaNFpScjI2emVFRlAvNUdpNkZWVng5OFI3RWl1?=
 =?utf-8?B?NGRUTm5TanN5L1FkOVV4dHhTNDVqUCtKV1ZmWkhzOWZTNGFOak8vS0g3Q2dO?=
 =?utf-8?B?cGFkV0c4S1hQcGhEUS9BL1hQTkszZXlROWVyK2taRExxY2xkSXM3V3l3dHpZ?=
 =?utf-8?B?S2Zrc2U5c0xudCt0Um42ZUpBRElWbitURll6YmdTcXJpV1BsVmJCdVUvbDR5?=
 =?utf-8?B?WXlHMFUrcHpQaTNKVnJzckFJWGhySGlYc283SHBSZmRxbS9YVHM2a0RTZldt?=
 =?utf-8?B?OHY3TTF1MkhieWFvd3BpalJONDMxMzRrRHc0MzJzT1pWMWxSMWYxbjAwQVoy?=
 =?utf-8?B?RHVTazFLbWwwWmFyS3V0U1J2ak5QM3ZQd1RpZko2Qzd3VW9wcmFrdmJBRUgr?=
 =?utf-8?B?UmtnR1VMQlk3a3haV3ZPa0lDM09DVU9HOTZSNW9sa1daMlR4MG9KRTdJU2pw?=
 =?utf-8?B?VzJLc3hNZFN1cmM2cnRFSFl5N292YmxLaXdNSjVyWTlBQmRuYkJvdmE0RVk2?=
 =?utf-8?B?WGo0djZtTVEzaTJIdHJrQlVVUm5JeTMyTkRLWFp3cnZ3enFMcEh3czVwa0NM?=
 =?utf-8?B?N3c9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 437d802e-e430-461c-b9a4-08dba9f8b879
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2023 08:03:11.8034
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: SppHvUg5erTYvfygdj5kszTZiNwmwxZL95HGZP/tz/js92oyNuIJcDAkHEPmiT/8ShAZORhANweuKrweYYzjCg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5382
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 8/31/2023 3:57 PM, David Hildenbrand wrote:
> On 31.08.23 03:40, Huang, Ying wrote:
>> Ryan Roberts <ryan.roberts@arm.com> writes:
>>
>>> On 15/08/2023 22:32, Huang, Ying wrote:
>>>> Hi, Ryan,
>>>>
>>>> Ryan Roberts <ryan.roberts@arm.com> writes:
>>>>
>>>>> Introduce LARGE_ANON_FOLIO feature, which allows anonymous memory to be
>>>>> allocated in large folios of a determined order. All pages of the large
>>>>> folio are pte-mapped during the same page fault, significantly reducing
>>>>> the number of page faults. The number of per-page operations (e.g. ref
>>>>> counting, rmap management lru list management) are also significantly
>>>>> reduced since those ops now become per-folio.
>>>>>
>>>>> The new behaviour is hidden behind the new LARGE_ANON_FOLIO Kconfig,
>>>>> which defaults to disabled for now; The long term aim is for this to
>>>>> defaut to enabled, but there are some risks around internal
>>>>> fragmentation that need to be better understood first.
>>>>>
>>>>> Large anonymous folio (LAF) allocation is integrated with the existing
>>>>> (PMD-order) THP and single (S) page allocation according to this policy,
>>>>> where fallback (>) is performed for various reasons, such as the
>>>>> proposed folio order not fitting within the bounds of the VMA, etc:
>>>>>
>>>>>                  | prctl=dis | prctl=ena   | prctl=ena     | prctl=ena
>>>>>                  | sysfs=X   | sysfs=never | sysfs=madvise | sysfs=always
>>>>> ----------------|-----------|-------------|---------------|-------------
>>>>> no hint         | S         | LAF>S       | LAF>S         | THP>LAF>S
>>>>> MADV_HUGEPAGE   | S         | LAF>S       | THP>LAF>S     | THP>LAF>S
>>>>> MADV_NOHUGEPAGE | S         | S           | S             | S
>>>>
>>>> IMHO, we should use the following semantics as you have suggested
>>>> before.
>>>>
>>>>                  | prctl=dis | prctl=ena   | prctl=ena     | prctl=ena
>>>>                  | sysfs=X   | sysfs=never | sysfs=madvise | sysfs=always
>>>> ----------------|-----------|-------------|---------------|-------------
>>>> no hint         | S         | S           | LAF>S         | THP>LAF>S
>>>> MADV_HUGEPAGE   | S         | S           | THP>LAF>S     | THP>LAF>S
>>>> MADV_NOHUGEPAGE | S         | S           | S             | S
>>>>
>>>> Or even,
>>>>
>>>>                  | prctl=dis | prctl=ena   | prctl=ena     | prctl=ena
>>>>                  | sysfs=X   | sysfs=never | sysfs=madvise | sysfs=always
>>>> ----------------|-----------|-------------|---------------|-------------
>>>> no hint         | S         | S           | S             | THP>LAF>S
>>>> MADV_HUGEPAGE   | S         | S           | THP>LAF>S     | THP>LAF>S
>>>> MADV_NOHUGEPAGE | S         | S           | S             | S
>>>>
>>>>  From the implementation point of view, PTE mapped PMD-sized THP has
>>>> almost no difference with LAF (just some small sized THP).  It will be
>>>> confusing to distinguish them from the interface point of view.
>>>>
>>>> So, IMHO, the real difference is the policy.  For example, prefer
>>>> PMD-sized THP, prefer small sized THP, or fully auto.  The sysfs
>>>> interface is used to specify system global policy.  In the long term, it
>>>> can be something like below,
>>>>
>>>> never:      S               # disable all THP
>>>> madvise:                    # never by default, control via madvise()
>>>> always:     THP>LAF>S       # prefer PMD-sized THP in fact
>>>> small:      LAF>S           # prefer small sized THP
>>>> auto:                       # use in-kernel heuristics for THP size
>>>>
>>>> But it may be not ready to add new policies now.  So, before the new
>>>> policies are ready, we can add a debugfs interface to override the
>>>> original policy in /sys/kernel/mm/transparent_hugepage/enabled.  After
>>>> we have tuned enough workloads, collected enough data, we can add new
>>>> policies to the sysfs interface.
>>>
>>> I think we can all imagine many policy options. But we don't really have much
>>> evidence yet for what it best. The policy I'm currently using is intended to
>>> give some flexibility for testing (use LAF without THP by setting sysfs=never,
>>> use THP without LAF by compiling without LAF) without adding any new knobs at
>>> all. Given that, surely we can defer these decisions until we have more data?
>>>
>>> In the absence of data, your proposed solution sounds very sensible to me. But
>>> for the purposes of scaling up perf testing, I don't think its essential given
>>> the current policy will also produce the same options.
>>>
>>> If we were going to add a debugfs knob, I think the higher priority would be a
>>> knob to specify the folio order. (but again, I would rather avoid if possible).
>>
>> I totally understand we need some way to control PMD-sized THP and LAF
>> to tune the workload, and nobody likes debugfs knob.
>>
>> My concern about interface is that we have no way to disable LAF
>> system-wise without rebuilding the kernel.  In the future, should we add
>> a new policy to /sys/kernel/mm/transparent_hugepage/enabled to be
>> stricter than "never"?  "really_never"?
> 
> Let's talk about that in a bi-weekly MM session. (I proposed it as a topic for next week).

The time slot of the meeting is not friendly to our timezone. Like
it's 1 or 2 AM. Yes. I know it's very hard to find a good time slot
for US, EU and Asia. :(.

So maybe we still need to discuss it through mail?


Regards
Yin, Fengwei

> 
> As raised in another mail, we can then discuss
> * how we want to call this feature (transparent large pages? there is
>   the concern that "THP" might confuse users. Maybe we can consider
>   "large" the more generic version and "huge" only PMD-size, TBD)
> * how to expose it in stats towards the user (e.g., /proc/meminfo)
> * which minimal toggles we want
> 
> I think there *really* has to be a way to disable it for a running system, otherwise no distro will dare pulling it in, even after we figured out the other stuff.
> 
> Note that for the pagecache, large folios can be disabled and distributions are actively making use of that.
>