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 152F2C3271F for ; Fri, 5 Jul 2024 09:13:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A04126B009C; Fri, 5 Jul 2024 05:13:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B3F76B009D; Fri, 5 Jul 2024 05:13:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87B8F6B00A8; Fri, 5 Jul 2024 05:13:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 670C76B009C for ; Fri, 5 Jul 2024 05:13:15 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 189EB1413EA for ; Fri, 5 Jul 2024 09:13:15 +0000 (UTC) X-FDA: 82305135150.21.E0A51B6 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf29.hostedemail.com (Postfix) with ESMTP id 22D51120019 for ; Fri, 5 Jul 2024 09:13:12 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720170780; 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=VJdOUg113tejOx2XfXj50f/1qci0rRbOLDjGg+QdG/s=; b=c0FBcWMtvB5+Wh6EhBUe04mnoVR8lhYXl6gxpuifTpll0VAeDbNi2bCAA0nGp7DZUzVhr6 HroCf3UtEz9ZFpo9+PB6SxmCaNYPdCuJy/4IKyQG+w3R+Su18XoiDgxJ+u7OaBL6E3GwJr geIpBxpqJ8TGcU+5ixlA3LyP+yfhBqc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720170780; a=rsa-sha256; cv=none; b=M0yeSF9vdHWYlitXk5AqAZfu/A/FMsxeN6yj85gCEmVNpIa7PESmj4KqJQVKAGvUNmQSdk 71/AOV6l3xfgxLVlaSr45LVMNp2DqQR/+3INjfL2OM0JPTpxhuzrv0b514iqfBogZr/ue8 +ygyhAB6rmNB1LE2RAvCNDhTRU9JT1M= 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 5A4C3367; Fri, 5 Jul 2024 02:13:37 -0700 (PDT) Received: from [10.57.74.223] (unknown [10.57.74.223]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 366AF3F762; Fri, 5 Jul 2024 02:13:09 -0700 (PDT) Message-ID: <8d3804ad-14c8-4041-8f52-58fd9dd8d4b4@arm.com> Date: Fri, 5 Jul 2024 10:13:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 0/6] add mTHP support for anonymous shmem Content-Language: en-GB To: David Hildenbrand , Baolin Wang , Matthew Wilcox Cc: akpm@linux-foundation.org, hughd@google.com, wangkefeng.wang@huawei.com, ying.huang@intel.com, 21cnbao@gmail.com, shy828301@gmail.com, ziy@nvidia.com, ioworker0@gmail.com, da.gomez@samsung.com, p.raghav@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <27beaa0e-697e-4e30-9ac6-5de22228aec1@redhat.com> <6d4c0191-18a9-4c8f-8814-d4775557383e@redhat.com> <32f04739-0cd0-4a9e-9419-c5a13c333c28@redhat.com> From: Ryan Roberts In-Reply-To: <32f04739-0cd0-4a9e-9419-c5a13c333c28@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 22D51120019 X-Stat-Signature: 3s76u7qtbaha6zt5ofptxhtorzyqjzap X-Rspam-User: X-HE-Tag: 1720170792-132102 X-HE-Meta: U2FsdGVkX18A/BX0vRCDx+n7uP3XJToVKNFJI1VZkxXsS/cngNrI0W/o6AFCxgfzKKv8huyLF2/o7559QUcEthPireVnS117Fjdzz97c5jgCO574D9hX4fYzysU8Dx0euZqXjG49Mi3IaJTj/zQuoYPpUGDIRyYBZTB5NhTIqSnSmcztqyTP35Z5k8/KUpPUG0oukDyNVKgM/LWRzsf0veKkySqipjBQyKOXmkV8EQRS31QRqXNjUx3+CN9U+p+gkbUg0zLSFBSihR65OlI/Sna3KEBiIuIkig9T/Fnr3ime0V8lERWxmqaFKRrY1UVwRT2hSrsPbHzUaYQ8bSBgotnW14PlwmNWLSmOAQvo/rq4AZBPgz739tzdAPpAFaz4mwlf/Vx1PXL0NwGijUYfXmdzeNcwjSrohFjcKT5TEbGxK2DP/Iu5JtpoYRR+DBOBcisQW65iaL3j5usPFNaBhbQ0p5SBaD74u6XSKOayHRfllRh5aASptJGue8WN8bM+3b6S6VY+N9+du5MVfWjniw+H4+Kp5JRXKrrV35+9j32gJbpulbxnpXg9hvctpvhk1e4xABcp2wOhpgwFzyyEQwR/8yHGX/pGNdcBv0ffFGPyJxDqj+Nmcu4deQEt3i+7eHuTNX3QOrA32i2kztqBooCHJyJzc7dile/2kXo5kOuGidJE3DSkS59pVbbl8Cy/pOaypHcL9EXd9nNszgTSAFwP6YPV0nTWI7bm06Mwmlniq9NHsknqX+IXJ91eryJPD6VNGkNVL0XsUDsoPmz3+3j0FGPH4RV+kiWX9VujJb6O3YyQxRT884IR0owkL0HBXWw0xVy6raUXAFgtfyFLl5KzvJbVLqX+RUf1tWATx0Lvn5CqlNlPlDzPZwx3oHclBu8AnenZSoGxPe0j0nUM7VC5ITU/wQq/mSMDeY43yl4CNMb6KamVhs5lISFSh8IYJZ3xZFg4c/v1vF3cGxV 1kvnFAQ0 wqutFNnNHgyA7uCQaUbcBmncymk4pKOCRNzf63uMSQj2XgSgci3BJVdw4HYczUHOrNreA/SX8BfNC6JBHc1v9l0vBLB42JNU03tJpqa9QOacLMqEY6yk8JIaq/p2n48dKkNJijjA9gdtGn4XuX806XiLd2Zonm6Zh5j48BYNrdTgN0kTusiWcodDkUHknzvmT9JHjfHnZoRkywidu6KbYVpk29tACTVka/4wxndM8YZ4DmOG/pwsUmB5V6V2M49muzgqGC2sXxVWa8Va4YZUFrlTo0Rk31nDN+uMFPF1gqR4rl1UTsIyMxIg+pw== 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 05/07/2024 09:59, David Hildenbrand wrote: > On 05.07.24 10:45, Ryan Roberts wrote: >> On 05/07/2024 06:47, Baolin Wang wrote: >>> >>> >>> On 2024/7/5 03:49, Matthew Wilcox wrote: >>>> On Thu, Jul 04, 2024 at 09:19:10PM +0200, David Hildenbrand wrote: >>>>> On 04.07.24 21:03, David Hildenbrand wrote: >>>>>>> shmem has two uses: >>>>>>> >>>>>>>      - MAP_ANONYMOUS | MAP_SHARED (this patch set) >>>>>>>      - tmpfs >>>>>>> >>>>>>> For the second use case we don't want controls *at all*, we want the >>>>>>> same heiristics used for all other filesystems to apply to tmpfs. >>>>>> >>>>>> As discussed in the MM meeting, Hugh had a different opinion on that. >>>>> >>>>> FWIW, I just recalled that I wrote a quick summary: >>>>> >>>>> https://lkml.kernel.org/r/f1783ff0-65bd-4b2b-8952-52b6822a0835@redhat.com >>>>> >>>>> I believe the meetings are recorded as well, but never looked at recordings. >>>> >>>> That's not what I understood Hugh to mean.  To me, it seemed that Hugh >>>> was expressing an opinion on using shmem as shmem, not as using it as >>>> tmpfs. >>>> >>>> If I misunderstood Hugh, well, I still disagree.  We should not have >>>> separate controls for this.  tmpfs is just not that special. >> >> I wasn't at the meeting that's being referred to, but I thought we previously >> agreed that tmpfs *is* special because in some configurations its not backed by >> swap so is locked in ram? > > There are multiple things to that, like: > > * Machines only having limited/no swap configured > * tmpfs can be configured to never go to swap > * memfd/tmpfs files getting used purely for mmap(): there is no real >   difference to MAP_ANON|MAP_SHARE besides the processes we share that >   memory with. > > Especially when it comes to memory waste concerns and access behavior in some > cases, tmpfs behaved much more like anonymous memory. But there are for sure > other use cases where tmpfs is not that special. > > My opinion is that we need to let people configure orders (if you feel like it, > configure all), but *select* the order to allocate based on readahead > information -- in contrast to anonymous memory where we start at the highest > order and don't have readahead information available. That approach is exactly what I proposed to start playing with yesterday [1] for regular pagecache folio allocations too :) [1] https://lore.kernel.org/linux-mm/bdde4008-60db-4717-a6b5-53d77ab76bdb@arm.com/ > > Maybe we need different "order allcoation" logic for read/write vs. fault, not > sure. > > But I don't maintain that code, so I can only give stupid suggestions and repeat > what I understood from the meeting with Hugh and Kirill :) >