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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 256D5C4345F for ; Wed, 24 Apr 2024 14:20:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 94BAE6B0292; Wed, 24 Apr 2024 10:20:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FBFA6B0293; Wed, 24 Apr 2024 10:20:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79CD08D0011; Wed, 24 Apr 2024 10:20:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5C0676B0292 for ; Wed, 24 Apr 2024 10:20:14 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 149E6A144D for ; Wed, 24 Apr 2024 14:20:14 +0000 (UTC) X-FDA: 82044635148.21.0A5665B Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id 3B5741C0025 for ; Wed, 24 Apr 2024 14:20:12 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713968412; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=auW51NggN3l8LLS1yptgNM+YyTrSsOUhW5J/KXFqbLs=; b=ZP46JYbwH3XoHldL22a/lZD/lLPXg31qLiu9wCcSxX3nFNSyeHXGfWGobLrbXWvsRiqBQG 8BkKPDoaN6tmBTFjarpyoxV5PFYJfs7sPzRlX8fjH0gfrk7kBDywYBRvDgxtwE/T5QypEK tiPaGG2KdNp07xMgOb0nwAVDhjYW8xc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713968412; a=rsa-sha256; cv=none; b=mTyJPdOAh0eWC2ScjqrxMkMxvPx80NCkIQVkJD5lu6fSmxTtApHSqD7Bfczn9gWXOp44rv 422dPgw9h0FJf/xrqTgyjGfa27dcpWQq5Cs4tPCsCXEOF+01cYvdt4a6NfJj+MAd3w4u05 NoOlyLYRTy+7kY9Tzdr+se1aP3Qe9n8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@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 117ED2F; Wed, 24 Apr 2024 07:20:39 -0700 (PDT) Received: from [10.1.25.156] (XHFQ2J9959.cambridge.arm.com [10.1.25.156]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C8B693F7BD; Wed, 24 Apr 2024 07:20:09 -0700 (PDT) Message-ID: <76f816dd-3bbf-48c9-a630-3787051cf289@arm.com> Date: Wed, 24 Apr 2024 15:20:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/5] add mTHP support for anonymous share pages Content-Language: en-GB To: Baolin Wang , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, david@redhat.com, wangkefeng.wang@huawei.com, 21cnbao@gmail.com, ying.huang@intel.com, shy828301@gmail.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <4b998e7d-153f-48cc-a9bb-8c84bb675581@arm.com> <80b5f87e-c156-4ccc-98f0-96f1fd864273@arm.com> <5b8b22e7-6355-4b08-b5b5-1e33ebae6f16@arm.com> <813fe7fd-3004-4e8b-801d-95c33559a025@linux.alibaba.com> From: Ryan Roberts In-Reply-To: <813fe7fd-3004-4e8b-801d-95c33559a025@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: bxuz5h3gth8fftaapt5cnd4eo5a9m53q X-Rspamd-Queue-Id: 3B5741C0025 X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1713968412-146396 X-HE-Meta: U2FsdGVkX1/qeVygRUG9qQ8jrdR0p4/2M6+M+1hkiv++lYdD2GgGK0sb1Y1Q2Kcf58lok5U9DLNq03xph0ljip24n4bL67bsbEAaQD+sksEQi3q+OeC5PhYeySpyqzXEVVCpMXXdJwQB0vYaJRi30hxfbqJ1OI/D7i8OMjYNjmO5dXTE30XK841bkABvQJNkMhnYOy/oMJMeaKd6NhfGofB2B5k7HlgwN8p9sy+UWH0svCfc2+DcqUb7elq2au+mFtB2BJ7Iyi9vEYC5hcwoWRavqAukux6RC2qxr59i81PLqQ1s6krZ7O8P0lNyXj59ZR7iRJasiMKtDzpYRlXMgNPe2/o45N8RKCIeF+t2AskoKGmH5m3Mg4fIA0WAVPsqmvkT3Gha3XsY7HOMM3WGsAdvm1dnMq3Z/w9CPsEmhmMb0etzgDGGC2ia1RKEULhj40z1UmZuUb4U+vAWBchxhZMppJJ8IkOOtpZkOi/E/M0y/iBe0T7deiw3wMAq+0fxwYcwxirZcBUjUVqZP1nC1bYvwM7Cur2KvYdleWHYBzaRBjQLEDOKKUOnFrWNxA7s9W+k7Y5s349KoUVvP5xElsgdT81cVNBXbUyDFlRmbdtEhtzvxhbwPs8yTCtohFUTTb67eRtmeWKsJSpNaIPx0bWP6SzYmOHlWhpbvasjU8HThitLUwYqlD8AQHlysbPAu+v0jwZExmRY9Af95g8dy7QpMG+ohwkzLRDiYjtD8lCgPf9ShK/zA5xH6be+p0H0wcnIMQMiKyvhgL07soqA4Fu9ct0kIH+rkiptjWvFI4GbAYNQZG37jM3lmaeT4qUv6OoVVZoPZ+kwuskD7wau8ly6ZduxOpUfzTLo+vrTndwOyEZURPZVyu1qlAVKDBcpvhSzf9O7PW0qrVDTWwnODj0IX/EIkLMGrWwUoALxlmc0c5B+dEGPUKk399x3b/iblg+Vmoy7KxXrNC0uQxm 9DRVFdU2 xSgSKbH9/xoXqPapnuyklNhH0ksS1e3lck/Suy5CW9oKYsMQMGHZU9g40p7x6x0S9jZ27aSIpalyvDj3tJGcw+byEUVGJVbinD2Bvyhr5OMQRAp9rFq/Kd9a8a7ozPFH9M1t4ATPxZw1a1o0H8XwnQkUq1FRER1fXF7l2YdaNqiKkJcoToMx+BqRQ26kuqvBSCtyE 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: List-Subscribe: List-Unsubscribe: On 24/04/2024 14:49, Baolin Wang wrote: > > > On 2024/4/24 18:01, Ryan Roberts wrote: >> On 24/04/2024 10:55, Baolin Wang wrote: >>> >>> >>> On 2024/4/24 16:26, Ryan Roberts wrote: >>>> On 24/04/2024 07:55, Baolin Wang wrote: >>>>> >>>>> >>>>> On 2024/4/23 18:41, Ryan Roberts wrote: >>>>>> On 22/04/2024 08:02, Baolin Wang wrote: >>>>>>> Anonymous pages have already been supported for multi-size (mTHP) allocation >>>>>>> through commit 19eaf44954df, that can allow THP to be configured through the >>>>>>> sysfs interface located at >>>>>>> '/sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled'. >>>>>>> >>>>>>> However, the anonymous shared pages will ignore the anonymous mTHP rule >>>>>>> configured through the sysfs interface, and can only use the PMD-mapped >>>>>>> THP, that is not reasonable. Many implement anonymous page sharing through >>>>>>> mmap(MAP_SHARED | MAP_ANONYMOUS), especially in database usage scenarios, >>>>>>> therefore, users expect to apply an unified mTHP strategy for anonymous >>>>>>> pages, >>>>>>> also including the anonymous shared pages, in order to enjoy the benefits of >>>>>>> mTHP. For example, lower latency than PMD-mapped THP, smaller memory bloat >>>>>>> than PMD-mapped THP, contiguous PTEs on ARM architecture to reduce TLB miss >>>>>>> etc. >>>>>> >>>>>> This sounds like a very useful addition! >>>>>> >>>>>> Out of interest, can you point me at any workloads (and off-the-shelf >>>>>> benchmarks >>>>>> for those workloads) that predominantly use shared anon memory? >>>>> >>>>> As far as I know, some database related workloads make extensive use of shared >>>>> anonymous page, such as PolarDB[1] in our Alibaba fleet, or MySQL likely also >>>>> uses shared anonymous memory. And I still need to do some investigation to >>>>> measure the performance. >>>>> >>>>> [1] https://github.com/ApsaraDB/PolarDB-for-PostgreSQL >>>> >>>> Thanks for the pointer! >>>> >>>>> >>>>>>> The primary strategy is that, the use of huge pages for anonymous shared >>>>>>> pages >>>>>>> still follows the global control determined by the mount option "huge=" >>>>>>> parameter >>>>>>> or the sysfs interface at >>>>>>> '/sys/kernel/mm/transparent_hugepage/shmem_enabled'. >>>>>>> The utilization of mTHP is allowed only when the global 'huge' switch is >>>>>>> enabled. >>>>>>> Subsequently, the mTHP sysfs interface >>>>>>> (/sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled) >>>>>>> is checked to determine the mTHP size that can be used for large folio >>>>>>> allocation >>>>>>> for these anonymous shared pages. >>>>>> >>>>>> I'm not sure about this proposed control mechanism; won't it break >>>>>> compatibility? I could be wrong, but I don't think shmem's use of THP used to >>>>>> depend upon the value of /sys/kernel/mm/transparent_hugepage/enabled? So it >>>>> >>>>> Yes, I realized this after more testing. >>>>> >>>>>> doesn't make sense to me that we now depend upon the >>>>>> /sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled values (which by >>>>>> default disables all sizes except 2M, which is set to "inherit" from >>>>>> /sys/kernel/mm/transparent_hugepage/enabled). >>>>>> >>>>>> The other problem is that shmem_enabled has a different set of options >>>>>> (always/never/within_size/advise/deny/force) to enabled >>>>>> (always/madvise/never) >>>>>> >>>>>> Perhaps it would be cleaner to do the same trick we did for enabled; >>>>>> Introduce >>>>>> /mm/transparent_hugepage/hugepage-XXkb/shmem_enabled, which can have all the >>>>>> same values as the top-level >>>>>> /sys/kernel/mm/transparent_hugepage/shmem_enabled, >>>>>> plus the additional "inherit" option. By default all sizes will be set to >>>>>> "never" except 2M, which is set to "inherit". >>>>> >>>>> Sounds good to me. But I do not want to copy all same values from top-level >>>>> '/sys/kernel/mm/transparent_hugepage/shmem_enabled': >>>>> always within_size advise never deny force >>>>> >>>>> For mTHP's shmem_enabled interface, we can just keep below values: >>>>> always within_size advise never >>>>> >>>>> Cause when checking if mTHP can be used for anon shmem, 'deny' is equal to >>>>> 'never', and 'force' is equal to 'always'. >>>> >>>> I'll admit it wasn't completely clear to me after reading the docs, but my >>>> rough >>>> understanding is: >>>> >>>>    - /sys/kernel/mm/transparent_hugepage/shmem_enabled controls >>>>      mmap(SHARED|ANON) allocations (mostly; see rule 3) >>>>    - huge=... controls tmpfs allocations >>>>    - deny and force in shmem_enabled are equivalent to never and always for >>>>      mmap(SHARED|ANON) but additionally override all tmpfs mounts so they >>>> act as >>>>      if they were mounted with huge=never or huge=always >>>> >>>> Is that correct? If so, then I think it still makes sense to support per-size >>> >>> Correct. >>> >>>> deny/force. Certainly if a per-size control is set to "inherit" and the >>>> top-level control is set to deny or force, you would need that to mean >>>> something. >>> >>> IMHO, the '/mm/transparent_hugepage/hugepage-XXkb/shmem_enabled' interface >>> should only control the anonymous shmem. And 'huge=' controls tmpfs allocation, >>> so we should not use anonymous control to override tmpfs control, which seems a >>> little mess? >> >> I agree it would be cleaner to only handle mmap(SHARED|ANON) here, and leave the >> tmpfs stuff for another time. But my point is that >> /mm/transparent_hugepage/shmem_enabled already interferes with tmpfs if the >> value is deny or force. So if you have: >> >> echo deny > /mm/transparent_hugepage/shmem_enabled > > IIUC, this global control will cause shmem_is_huge() to always return false, so > no matter how '/mm/transparent_hugepage/hugepage-xxxkB/shmem_enabled' is set, > anonymous shmem will not use mTHP. No? No, that's not how '/mm/transparent_hugepage/hugepage-xxxkB/enabled' works, and I think '/mm/transparent_hugepage/hugepage-xxxkB/shmem_enabled' should follow the established pattern. For anon-private, each size is controlled by its /mm/transparent_hugepage/hugepage-xxxkB/enabled value. Unless that value is "inherit", in which case the value in /mm/transparent_hugepage/enabled is used for that size. That approach enables us to 1) maintain back-compat and 2) control each size independently 1) is met because the default is that all sizes are initially set to "never", except the PMD-size (e.g. /mm/transparent_hugepage/hugepage-2048kB/enabled) which is initially set to inherit. So any mTHP unaware SW can still modify /mm/transparent_hugepage/enabled and it will still only apply to PMD size. 2) is met because mTHP aware SW can come along and e.g. enable the 64K size (echo always > /mm/transparent_hugepage/hugepage-64kB/enabled) without having to modify the value in /mm/transparent_hugepage/enabled. > >> echo inherit > /mm/transparent_hugepage/hugepage-64kB/shmem_enabled >> >> What does that mean? So I think /mm/transparent_hugepage/hugepage-xxxkB/shmem_enabled will need to support the deny and force values. When applied to non-PMD sizes, "deny" can just be a noop for now, because there was no way to configure a tmpfs mount for non-PMD size THP in the first place. But I'm not sure what to do with "force"? >> >>> >>>>>> Of course the huge= mount option would also need to take a per-size option in >>>>>> this case. e.g. huge=2048kB:advise,64kB:always >>>>> >>>>> IMO, I do not want to change the global 'huge=' mount option, which can >>>>> control >>>>> both anon shmem and tmpfs, but mTHP now is only applied for anon shmem. So >>>>> let's >>>> >>>> How does huge= control anon shmem? I thought it was only for mounted >>>> filesystems; so tmpfs? Perhaps my mental model for how this works is broken... >>> >>> Sorry for noise, you are right. So this is still the reason I don't want to >>> change the semantics of 'huge=', which is used to control tmpfs. >>> >>>>> keep it be same with the global sysfs interface: >>>>> /sys/kernel/mm/transparent_hugepage/shmem_enabled. >>>>> >>>>> For tmpfs large folio strategy, I plan to address it later, and we may need >>>>> more >>>>> discussion to determine if it should follow the file large folio strategy >>>>> or not >>>>> (no investigation now). >>>> >>>> OK. But until you get to tmpfs, you'll need an interim definition for what it >>>> means if a per-size control is set to "inherit" and the top-level control is >>>> set >>>> to deny/force. >>>> >>>>> >>>>> Thanks for reviewing. >>>> >>>> No problem! Thanks for doing the work! >>>> >>>>> >>>>>>> TODO: >>>>>>>     - More testing and provide some performance data. >>>>>>>     - Need more discussion about the large folio allocation strategy for a >>>>>>> 'regular >>>>>>> file' operation created by memfd_create(), for example using >>>>>>> ftruncate(fd) to >>>>>>> specify >>>>>>> the 'file' size, which need to follow the anonymous mTHP rule too? >>>>>>>     - Do not split the large folio when share memory swap out. >>>>>>>     - Can swap in a large folio for share memory. >>>>>>> >>>>>>> Baolin Wang (5): >>>>>>>      mm: memory: extend finish_fault() to support large folio >>>>>>>      mm: shmem: add an 'order' parameter for shmem_alloc_hugefolio() >>>>>>>      mm: shmem: add THP validation for PMD-mapped THP related statistics >>>>>>>      mm: shmem: add mTHP support for anonymous share pages >>>>>>>      mm: shmem: add anonymous share mTHP counters >>>>>>> >>>>>>>     include/linux/huge_mm.h |   4 +- >>>>>>>     mm/huge_memory.c        |   8 ++- >>>>>>>     mm/memory.c             |  25 +++++++--- >>>>>>>     mm/shmem.c              | 107 ++++++++++++++++++++++++++++++---------- >>>>>>>     4 files changed, 108 insertions(+), 36 deletions(-) >>>>>>>