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 DB26BC3271F for ; Fri, 5 Jul 2024 08:45:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E5CD6B0098; Fri, 5 Jul 2024 04:45:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66E8B6B0099; Fri, 5 Jul 2024 04:45:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50E8B6B009A; Fri, 5 Jul 2024 04:45:12 -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 32A536B0098 for ; Fri, 5 Jul 2024 04:45:12 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D4CC4141764 for ; Fri, 5 Jul 2024 08:45:11 +0000 (UTC) X-FDA: 82305064422.18.14EF392 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf04.hostedemail.com (Postfix) with ESMTP id A154A40012 for ; Fri, 5 Jul 2024 08:45:09 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.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=1720169097; 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=S1Vd7Usz1DtT3NU2GaCUI+Uu6TAzIsbTiSpZzFCTDBY=; b=OPykUOHZaw4eHWESPVdkAAWh2jkz4xYLZEqJ4kuD7CvF0a7RrOJ056IT9CrJXwNW7k8sKs vWaQpcw/70pizQxKPJuRieeU8mzQpUPUBDfQY9ITcAdxml+VgFFUOkhNWdN5ioHio9tLfL hopojA2j4xjzc95Tgp0TyJRVaWHvEQ4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.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=1720169097; a=rsa-sha256; cv=none; b=3nJ9jg7vHgQHiqzoy8qF2fUUeDd5gfWZP6M05nGS7gvYnJbTPoaPrCHuCr9coUVQdVsqh2 C2k8qbdFq6/od2waM5JSmGqI5FybgHEnGdqv4RJ/ELMoGj5Uc8WDiM9iOWl8v4ScT4pLdW drVi6xsnj1COB/y10QCm6hg3CHHtvaY= 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 1CB3E367; Fri, 5 Jul 2024 01:45:34 -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 0FAC73F762; Fri, 5 Jul 2024 01:45:06 -0700 (PDT) Message-ID: Date: Fri, 5 Jul 2024 09:45:05 +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: Baolin Wang , Matthew Wilcox , David Hildenbrand 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> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: A154A40012 X-Stat-Signature: miojkyqadaj7xgz31cb79tqzjxe1wfpt X-HE-Tag: 1720169109-35925 X-HE-Meta: U2FsdGVkX1+oZWOgtNEzr9bSp3/qLbJIR9iFOXjxKhp7UYHGpirO00fFf2prVqa6oGn7ZpmCUdBZtMotloj6TDHOzHkF74ErD5Tl6TouhPcfze4PqqS42miMVcsJdVuu6MscVm8J4MY5AYU6cLbtAeVhPfnqJ5aLnw5gorAE2K8Ial39GIkerJds484kmA5kLdJOh7P/DVhEiNoTs9D5e7BXzAHcT6PaEmtJUgmGmzHPCi82O+BLk2tuZdni/OTWS5CGw5YFqdFuwCH1jFeeFCWVVF+0SdkDEmN7CTnywLm+c5247ro7CqmJA1bxVqibPM+kov7bYxZf6l675qp5CDXKGSzqYFq8gmL8dok2R6Ia7ADYfikjMzPpRi+yK8rum1Ioam69B2MAry9jp9Hd++N0afMaXCBoGWhxwfUcMjXrH91s+kTPVMy8YJuOFNRQ/MjF+RqhIX/qVgkTCjr1FPaqyu8F0sVPIejukvoXuL88FqAPCijB1yZ8HT3bDg5IklO/Oj+cjs3MAFZQZmxhZpHuk5hpG1/miieVTuaX6op8BJRFiMVdYYv9nj1LuTZ0Kul1dPHofQpUeJMLU9BI9znAowRArNEoOTQAxOpb8RewF8FxiKQY+rF2mGpHVeJ23mtHt8Aob+9nbkzR8QAo71SBal+oIUFeIFx46f3av4k6hAabl8zhoSBZ/VJMd/vvML+lIuecYMqF6SL1dQcelnx7C1mYYljsuz6qf8mHhcleXJBL2FEsg+AiMxEiWvRuvSx5BgwFKLwBQjRQ3CXP1I2dWO9oCYbFZDXAO5OC2odGqjpmACU5tLsPWMAbTCe+a4i66Vqt/P6gMiGNLXIZ4bSes51Tuyy7fsaq0rXBHNvao7yMIPKDMEAYqzjDm0MXBeQnAL2MzFBlExQ/n7WTx+kMs2yAKIrwcSuslsHttptzRfS9rAQbx0ARIet8J1Lo32CvOHsfbFLoaCtJvZ8 ZqRpRDuT TA8a5pXIJLIuyz6MbzAPbsAOfUnkXMKTuALhYNNGujf4C3UYWHRHi414nLRcmS4GPLrjt26HCcstugeW3aqT2IWEA8T0+X0v3XS5pnvyH8A8Ihl6IqBhMbd3g+G1ibxlnH5RWEm7cobidg/t+mx3+9CqELBeJ2qVVHYmytDosWa14GKuIiYih4zNW6RDWqk+1AFyxINxrsX13ikXP2ENuR2Y1GNw3o9RtuuX3WUEhcjdx0fwmFeQnyECwZ5n4oCGnezBT 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 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? > > But now we already have a PMD-mapped THP control for tmpfs, and mTHP simply > extends this control to per-size. > > IIUC, as David mentioned before, for tmpfs, mTHP should act like a huge order > filter which should be respected by the expected huge orders in the write() and > fallocate() paths. This would also solve the issue of allocating huge orders in > writable mmap() path for tmpfs, as well as unifying the interface. > > Anyway, I will try to provide an RFC to discuss the mTHP for tmpfs approach.