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 C36E6D2127C for ; Thu, 17 Oct 2024 11:26:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41AE46B007B; Thu, 17 Oct 2024 07:26:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CB976B0082; Thu, 17 Oct 2024 07:26:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26BEA6B0083; Thu, 17 Oct 2024 07:26:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 093A96B007B for ; Thu, 17 Oct 2024 07:26:31 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 427791407E6 for ; Thu, 17 Oct 2024 11:26:19 +0000 (UTC) X-FDA: 82682865846.22.8B238F8 Received: from fout-a7-smtp.messagingengine.com (fout-a7-smtp.messagingengine.com [103.168.172.150]) by imf02.hostedemail.com (Postfix) with ESMTP id CCC4E80019 for ; Thu, 17 Oct 2024 11:26:09 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=shutemov.name header.s=fm1 header.b=iynDoyPt; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="h LsztB4"; dmarc=none; spf=pass (imf02.hostedemail.com: domain of kirill@shutemov.name designates 103.168.172.150 as permitted sender) smtp.mailfrom=kirill@shutemov.name ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729164281; a=rsa-sha256; cv=none; b=OfXTDRVXaFRsLpAqaNEYJoraTbZZ3vIb54XY8snJ8xqKNy66nDWSYjvVtNr2YivA72Y246 NvqkFSpxH7fafI8xF5stxrj0q8vBuV3F4zZJqX/bHYlFxUv4SSvHqbKxbSbk3F5pcHrOyF ECVWNjjebCk6Rf9+HFkRln4NkFar3eU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=shutemov.name header.s=fm1 header.b=iynDoyPt; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="h LsztB4"; dmarc=none; spf=pass (imf02.hostedemail.com: domain of kirill@shutemov.name designates 103.168.172.150 as permitted sender) smtp.mailfrom=kirill@shutemov.name ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729164281; 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:dkim-signature; bh=RKLdY9fSq4oo8drhIwNXN/BmgJJsKXWT1VoCp5OTUSE=; b=U0ZNpaPLHVa9tkuF1WfsxSbQrIQ2d6y6TkXdM1fvWSxoTbL0g83rvqhypoU/baFoOkdf9L HjmYlEQzVNENeYEqLa9b1GxSyi4v5SOMoExq4IyQ6FlLA5RjEQmf5YKmg8VjyPPWHVg5YP 5E3SDH6q0agUbI1mT2XLwBx/NFr7QZQ= Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id BD64F13801E7; Thu, 17 Oct 2024 07:26:27 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Thu, 17 Oct 2024 07:26:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm1; t=1729164387; x=1729250787; bh=RKLdY9fSq4oo8drhIwNXN/BmgJJsKXWT 1VoCp5OTUSE=; b=iynDoyPtNNLJU59lD+1kug96XY2iKi/+PB+w7H59arDACK5X 0dXVJtMT339t48qwGCGa/K60YvJnmh1vMKF+Oz2oUHpu6Vqhzx/Kzt/NYZXTXu45 9BayZ9l0TS5pZwpjYA7Edrmy7m0fF1BiOobrW3BBIuM1gQF8gdMCo5npQOyOcgC9 W77sk+gmhjXkATjgmNs3SIAH5ZZliyDxpl4kDIy5BjxQ3f0t1S8hqUopX6pHrHuM 7W4AYhUdntT9SrrDm9ec4+/nVYjkoEpkehJd9/ABuuUbIUy7ttEC5xNAsUoVnvsV T5wpPgiuosdiq8Cre5p7qNqv3WZMeSpScBz+Tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1729164387; x= 1729250787; bh=RKLdY9fSq4oo8drhIwNXN/BmgJJsKXWT1VoCp5OTUSE=; b=h LsztB4ZOpK9awXVcT6AYJUzmdQ7aIHUBYa5bk+FsthbhPAYw3b2KMvZlmKVSBW1p OEsFVEpN16mrRSnu/aqhe/BBl6MvG+BlIXe43Clx4yOjHyjq3A5TLMzvU0UxgGBq i92mi692DyFwJNz/IlDB5Bz9q1VGdI/rRwOBhh1jExQaggHMaOHC8GcAgPE3tZpV QzFdk0Op9BYZKdTE0cviMY752ynlCv+abscDQDaiva+g5FSG9yHiazUINT2dYyga jNwOo8MFYpRKr5qpXJPGOchlqbDeAgkzjdPpZOZ12VoLDlqJqXO1GCOpyOozC5p6 Qvc4WiNe8wyH2Ce6zZ7dQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdehuddggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggugfgjsehtkefstddttdej necuhfhrohhmpedfmfhirhhilhhlucetrdcuufhhuhhtvghmohhvfdcuoehkihhrihhllh esshhhuhhtvghmohhvrdhnrghmvgeqnecuggftrfgrthhtvghrnhepudeffeetffegteef jeetvdekgeelveeiheeiffeltddtgeeuffevvdehveevheffnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepkhhirhhilhhlsehshhhuthgvmhho vhdrnhgrmhgvpdhnsggprhgtphhtthhopedufedpmhhouggvpehsmhhtphhouhhtpdhrtg hpthhtohepsggrohhlihhnrdifrghngheslhhinhhugidrrghlihgsrggsrgdrtghomhdp rhgtphhtthhopeifihhllhihsehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtoheprg hkphhmsehlihhnuhigqdhfohhunhgurghtihhonhdrohhrghdprhgtphhtthhopehhuhhg hhgusehgohhoghhlvgdrtghomhdprhgtphhtthhopegurghvihgusehrvgguhhgrthdrtg homhdprhgtphhtthhopeifrghnghhkvghfvghnghdrfigrnhhgsehhuhgrfigvihdrtgho mhdprhgtphhtthhopedvudgtnhgsrghosehgmhgrihhlrdgtohhmpdhrtghpthhtoheprh ihrghnrdhrohgsvghrthhssegrrhhmrdgtohhmpdhrtghpthhtohepihhofihorhhkvghr tdesghhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Oct 2024 07:26:22 -0400 (EDT) Date: Thu, 17 Oct 2024 14:26:16 +0300 From: "Kirill A. Shutemov" To: Baolin Wang Cc: Matthew Wilcox , akpm@linux-foundation.org, hughd@google.com, david@redhat.com, wangkefeng.wang@huawei.com, 21cnbao@gmail.com, ryan.roberts@arm.com, ioworker0@gmail.com, da.gomez@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A . Shutemov" Subject: Re: [RFC PATCH v3 0/4] Support large folios for tmpfs Message-ID: <6dohx7zna7x6hxzo4cwnwarep3a7rohx4qxubds3uujfb7gp3c@2xaubczl2n6d> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: CCC4E80019 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 8i1exo1969mba3xuj148wrnh9c874oqn X-HE-Tag: 1729164369-407521 X-HE-Meta: U2FsdGVkX18upce9Lul2L1vemgms+gljlIuD0eQK1YuM9i7sEqE4K0jT9p0Np9ytLgw5Kgs7VPNF16yHj/9IMmQUXBYytuS6+vXGsclTr8imTDDO5skA1G8mUna39awd+yR3ml/WU3TxyJxSCEGDACE9UUNI3SF00O694XTc8gIYsDy1TR/cMyMffllIulzSU0D1I+WtXbfP23FtUow+TC+VAQ91NOA/ga0oCN5BbdRfRFCUb6q3wudVebm66aPnymo3Z8yVz1zNajPYsdpno+7NRh+vIMZycTnmC9K+VaQZ7/LaaZw4q/5m5eAo6SCKFwygJfpEVetHGaFIwaq8Hp2ZqziRF+xvLQpjx2Tx0UjJRwro23Ryc+9Tapp+BKtGgKUI1qqPd31aU2BvnsqZQ2RibI+KHx7WZXPJBM1n8w32OyFofOixnbUA2FcMC7gkzHGFfCR60pG0LA/1wn+/CMxG+UoA/Jjo9AfthkpV0Xd72m2v3cKHL0cBAX4VXoN6MgecZDe5rRTDmQPASIaAlzzlyfUtwpZPGjeynVLbsXpHu1ohIzW6WVtO30DV3JpO9Zy9sY0pww4rT+Msu4PfP4U7rKFmEjKlR3qw10zBf45iKWq/s5yAXAQvylvhe/QUBrjM4LR3nhiUR/y42L/TcdBFMNCVNBEPAECGkSg6zqpV/X3tYb+2MF6uZYYfmnXItMLXY3Tj5Ivhtz9qTKLZfuuzKFxTULebvXtf57Lh93qxsySefGiTVXiCi031wPZA9g6HqsI71+Zu2yetIkf5LGJ0PkXUYN7NyH34QjTF4Q/2uLtqetVwFJ1vftuK3FfE5C5mMjNxkB7luhvlyUHOUwGMwKm6pfCjsNugZ0X05aoKLf2BPBLw5ZLzXYCDZRhOAbLygMiVzLzxTpKvrWfc3gWxKesPe5kZtMnXwiEWvEg7JjpcGhfL/spedMAxY/4LDvMO5y+sGOnuxcCMJIh nqCKxsIi oS6kdI1OX7E25oi2CnkTUJdDqi8pxo9QgBHqAMWka6v5r1MDBwt5Rfw1uFgnXa/enDJ5jMickoCm/sGMN1KddHokAno7h8BhjwqfAu7twU/Km6UY5XmkdQPm94Q4OnSKYf0ugG/5fUrrZBHCIO1JvCWfBLAdBs5Hnd1kx+WURvNDBgaCyb4bnhOkmkL3JgnN21MNPFFG4w5u3oYEUtFxygOCejFdkxRlO4ot92F6TLMSVRsok19Z9c6XN2buzkEF84qJyRTr1I2oIeh+ocGnixZpysL150FGnsxdrVKaCYh0B9BPKREmYUE6Ml1RbPp0w5U5gNmg/1pYCg1HAYD83o5k0+7D4EG60aXyOIzc8OhHaJap2J58idFbraJS7vX0eVbpX2IP/xRV7oVE= 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 Thu, Oct 17, 2024 at 05:34:15PM +0800, Baolin Wang wrote: > + Kirill > > On 2024/10/16 22:06, Matthew Wilcox wrote: > > On Thu, Oct 10, 2024 at 05:58:10PM +0800, Baolin Wang wrote: > > > Considering that tmpfs already has the 'huge=' option to control the THP > > > allocation, it is necessary to maintain compatibility with the 'huge=' > > > option, as well as considering the 'deny' and 'force' option controlled > > > by '/sys/kernel/mm/transparent_hugepage/shmem_enabled'. > > > > No, it's not. No other filesystem honours these settings. tmpfs would > > not have had these settings if it were written today. It should simply > > ignore them, the way that NFS ignores the "intr" mount option now that > > we have a better solution to the original problem. > > > > To reiterate my position: > > > > - When using tmpfs as a filesystem, it should behave like other > > filesystems. > > - When using tmpfs to implement MAP_ANONYMOUS | MAP_SHARED, it should > > behave like anonymous memory. > > I do agree with your point to some extent, but the ‘huge=’ option has > existed for nearly 8 years, and the huge orders based on write size may not > achieve the performance of PMD-sized THP in some scenarios, such as when the > write length is consistently 4K. So, I am still concerned that ignoring the > 'huge' option could lead to compatibility issues. Yeah, I don't think we are there yet to ignore the mount option. Maybe we need to get a new generic interface to request the semantics tmpfs has with huge= on per-inode level on any fs. Like a set of FADV_* handles to make kernel allocate PMD-size folio on any allocation or on allocations within i_size. I think this behaviour is useful beyond tmpfs. Then huge= implementation for tmpfs can be re-defined to set these per-inode FADV_ flags by default. This way we can keep tmpfs compatible with current deployments and less special comparing to rest of filesystems on kernel side. If huge= is not set, tmpfs would behave the same way as the rest of filesystems. -- Kiryl Shutsemau / Kirill A. Shutemov