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 4C522D1AD5F for ; Wed, 16 Oct 2024 14:06:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A939E6B0083; Wed, 16 Oct 2024 10:06:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A44B76B0089; Wed, 16 Oct 2024 10:06:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90B876B008A; Wed, 16 Oct 2024 10:06:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 728806B0083 for ; Wed, 16 Oct 2024 10:06:22 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 938A3A04CF for ; Wed, 16 Oct 2024 14:06:03 +0000 (UTC) X-FDA: 82679639826.08.B73963D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 9D1714001A for ; Wed, 16 Oct 2024 14:06:12 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TuMm4XkT; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729087547; a=rsa-sha256; cv=none; b=Vp2a2WOuGDVPTgWv81rWOBYke/nYvZOyCDEt/mtNT9GguAShkfIbA7JDySN5FgzAWrAxLd skQNJPKjmNVerOTA6P+ce7z+cqVzFSm2H52qUYoTEPmwUSfzdz0UM3adeK3ruQEakHuiUZ 3n2ccJqR1fAik34abHcSAm+0yeWgEus= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TuMm4XkT; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729087547; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MTwPhUZumRV+Q0+GU7eL6HHhDSMy1l8O8nQqkevoH+8=; b=pxDkq0EYc3q4KGpwpzPLt7aEV2QGgYj4+hJQqGqlpopJjy9WK9k6twve9eAV8LiR3rXYvJ g2Cyfy2cIJq3i0uzl43RfZCFnbBK7phSDAn7YALkIcIqxg0TKDp6ZqY4ktjkU9CrS4/Pou qcrlqTD59eKk060fr6tvqk3RjRgIvUI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=MTwPhUZumRV+Q0+GU7eL6HHhDSMy1l8O8nQqkevoH+8=; b=TuMm4XkT0rn9Z5hcb8UjKqfR9U 8L/3YsW7L3Wl+A/8ro+wkTt2yYio+Kr3jzk5g+DBDzQL4z3zH3S62YK6VTAQPEIILGf8BhyPjBBZB Uavj0d4KqZTF/IASxIOGmWzUpCMIbNmLU8ALyRn/Y86cnfcJvAAQ3SL99qUK/sLLVCgPT2jZ+mc8j heVgWjQr1lZrW9twm8IqZdHAsh5eJO5BZ1nvr10TfBPoEMN7O778t5AR32NxfzDxmNF4J8Mt+/c/l Qf4F1jboyXmIbWTmwk3Duu3ZVuDOW/D9UTu9/G0Gy+y/FqfzD+UyTle/lxoNWGlz8/EXgIXEYvgbh dNj8EHZw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1t14f9-000000087IX-2WSK; Wed, 16 Oct 2024 14:06:07 +0000 Date: Wed, 16 Oct 2024 15:06:07 +0100 From: Matthew Wilcox To: Baolin Wang Cc: 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 Subject: Re: [RFC PATCH v3 0/4] Support large folios for tmpfs Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: gkgeufhrnqbb66zrd9ypuw9xpif4iii5 X-Rspamd-Queue-Id: 9D1714001A X-Rspamd-Server: rspam02 X-HE-Tag: 1729087572-829573 X-HE-Meta: U2FsdGVkX1/NDRrA9c4/LLX4FfBf1BCfZWyVqZde/r2vnqcH7oB+wJdPMtaKom5EJOrg08pVl9YIbQjWTUcYs3MAj/Dg6Qp+IQU7DZG7dOaiRNm+5sYYJVZc7dAjH3XsMPVG+GbSgx93a7v/G5VJ4jMOIY7Ar0Y/WduW2G2RbIB5FGHyqoCaocuXclOPV17b05tjmUzSfP+xXtACurK9R/Cqu5YAZPPSPdeBNOjocFoinKsuvRKUodSyntLLEHQXu+/J7SGlGf/oWghLu3Ci4qeUrtPI0oafUOM4hzKvlmgD6GhwwOsNZ+AQd7KlA5SrRJowdT1Lr8/M6Wz1G48JGH6iNEiT4TcvcUcXbTEga20NpjuAK2ifA5MzvbhM44dpjXjpBd052F9UAOJRS0y2dn4TpUSoucB2gfVnpc5TiWf1UaGYs5Ehsw0DH1tta439iOdDWxrbWM0/SY5cxQ1+ZXEaLNpLUW38qpkmbipRB+lBLAycnRCOFMep4v8jlADF7o4ntcDS243+kdq7VAeqhj37QDD9TgnJyUG4OM3gXpNixDkABArDpEwziMoDfJbg7yl6mab9kIhiWkLy/dVK+9T/NHtrNhqVJ/K6G33uGxSejph0ntwb1XzrZpSfVSAXFBokPk7PQIrW3M8WVpZXDQK0QJqL8ho2Stuf0FdqhOR0Z6KKseSbVgRCElSvk61L2cJexqIK+5pXRdbjlCxSdlscITJoEUs8vLykgQBKv0/t3LnisPXMHxInDIzvmZR2qK7w5Y7KfxnedlEFNZDZ7b3lxNw6BrAFzL4jGfNALOdby49QMJjj9xHj506wrQZXyn3YPioW6VNKfMiRg5KDRcfYF82mzy72rWyjrFoybRocTARYPaZL5sns5qx1+cuEOtXzKXzZIKc0yZcGP5lSTtGHdeaijJeQg8MhPlGkcCZ82fBIg0ejhrLIaWqCfYjeXbNl1IwLhBidS9LKGkj mSPyNce5 ObENeb787GjPzflcPTFkZg3jRB/QLzHwc2ym6BlsoXuv5fC47EMMyikEbYC2qwfRQRGiNsfA/gpdGoloYdwELkSizSefo1wM0K4DwrG4RK58IndTpaoawXK2YWrA8YL6Ecbr2mzp8XhWk/jTc4lP8ZGMMHPnXlB5NBNlNYfkk51ZAWLKrCcrvFOpRdJ0l3RrqBYyEEgvrTBBKHC6ssxfQxm87f9qzLRcpjFJy2d+UGauWYdI= 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 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. No more special mount options.