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 80757D1AD37 for ; Wed, 16 Oct 2024 09:29:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF2CA6B007B; Wed, 16 Oct 2024 05:29:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA40C6B0082; Wed, 16 Oct 2024 05:29:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6ABE6B0083; Wed, 16 Oct 2024 05:29:35 -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 978CE6B007B for ; Wed, 16 Oct 2024 05:29:35 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id ABEFF81C47 for ; Wed, 16 Oct 2024 09:29:26 +0000 (UTC) X-FDA: 82678942332.07.73FBEAA Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) by imf11.hostedemail.com (Postfix) with ESMTP id D9C3740003 for ; Wed, 16 Oct 2024 09:29:19 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=b9yMIeNv; spf=pass (imf11.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.99 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729070830; 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=xxFxERcJvuRvYGMsAAdT7h/9R3PvKzVYz/k10k5qIRM=; b=t7/Z+nfTTMTzg8WXB9J/qm6HNPmS5fjkWtpKbNc8wNRnBEqYhBFCgqFsJ5hkSccXz+eLpc pAQ5o+eyd+VpYioBmsVQkVkUfNpK5aU1bLmbpF1yhFmHSGrTObZC87pxrSpdTLIr3ZShhw XOZnxUATfIA2UjiNVxYyac7DrBMG7tI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729070830; a=rsa-sha256; cv=none; b=6NaXSpFSgGbm2i48g5A98DVezt8Ijp4h2NdfrVyfZenWSbqy/kSD/+RIYkQnLxypV99/yD TYIuKrmte+/d3eiNyudGL0RR3+oqAoiwz3Z/X9JbATlhLBx/RBOCqOxerjRA/7EcyguXmX EYHb4A0FknnbIZof9B5jTRoPVY6+9co= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=b9yMIeNv; spf=pass (imf11.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.99 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1729070962; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=xxFxERcJvuRvYGMsAAdT7h/9R3PvKzVYz/k10k5qIRM=; b=b9yMIeNvgTgLlDM2zQLcYU2G84+Oc6/MoXrso1U3WMFtCFbIqJO3TQJML22uae+lyY4nZHh3e+BeBsnMcgWjv5DZz6KzWB2c3fIRZZkd9uAtyrjPYc206oQrbeRJ6GKXDi6NJPHz1gQ/P0uapPcec3fbih6rvrpxvldTd0owaLw= Received: from 30.74.144.157(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WHGvQyY_1729070960 cluster:ay36) by smtp.aliyun-inc.com; Wed, 16 Oct 2024 17:29:20 +0800 Message-ID: <584662fb-cb1f-4b2c-9075-f70d31473c9d@linux.alibaba.com> Date: Wed, 16 Oct 2024 17:29:19 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v3 0/4] Support large folios for tmpfs To: Kefeng Wang , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, david@redhat.com, 21cnbao@gmail.com, ryan.roberts@arm.com, ioworker0@gmail.com, da.gomez@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <007880ac-d73f-4eef-9978-a4f844338522@huawei.com> From: Baolin Wang In-Reply-To: <007880ac-d73f-4eef-9978-a4f844338522@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D9C3740003 X-Stat-Signature: ywmimd73gcoczmc6h1ahgnqjqfpc1ob8 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729070959-814884 X-HE-Meta: U2FsdGVkX19hD5FxLI1dehqk+r5UV5NQV39kleEEiKp5hZ66lbuQ2EtDo2yNVFklC2MSz04525MlqwPmIxrgYiZ2Nv5So9S0F9saxACUUMZwnoPSPMQyd70B8SSkYvB5tJQhc52l9ChFWbCkQFHFF3b/I9zJiuaLQT5xqO2ToqSzMGqg4d/RraXEtTuqV4Jq+tlz4ZARM5hIgu7X9OWM9pcBTwQBw4ruSpbV3bocGmQFGau+NUTfXOHkgxsY9PAdxaoeNUgTFItzkqZixsxD/D1KpFvpc/hPArFaER2U0mQmrDf7nEky4uYCLZh54inChSv4jDBbGyLrSM+MVIFU7sGRfDokYdg5PD4IRZXnpYG72KtbECaxAgdnjfzpuiem+8Ve9pvMoLaYRwv3H7KIWg62d3ZBxHpTn5ZL2llpPHvucuZkffpPVJu/KIzqNsBVOBW9bC7AorZmcEz2UY6G2ovezEuBBXcMTH9EX5wrpwyRhyplzUyxJ6/WFFZRn647Oo0BPsvOCklvrqFwf+mtm72Tggg+FzXVC6BBnMkU4WvKgePnei5m3ms8xzb3rYvYuZ5tbcPLTWKST3E1G2U3KInp3D62zDcWzVod7pWbCT3epKigmkcO7ECFv+zwmQAJ3mFgPwYWcXjFn3FdoUhU8ADe6KUiGyiythEAqKIKwxZl8EK3vje6g9n65SQfekRJ4geOgRwpsyeQ15UwFEkpwBdSGxBIFZy7N8eq6HUNub+vMsM8jjjvB09yOTv9NxKLXN/eyiyc1vLbJcBEVDNlMCoRyGonyAKOOM7SLWUPAlkELRheN2yVlzf6r2I1u7mF1tKO33+y+YB9JRLU8SFffQnTEynepzQrASOpUMmo3ppY8s87s66721CLpxmH4ih65VCR0zA2Nfo77NTGUFTp4422sm584Vfwtp1b5zx4bb2X0fzBBlvtrrxIGIZdPZPO26aVFyPTcbbOHmUV2wV qlvm2Fxy GHSngfTpGHZl9aAaf133734t7RAH/fW80OBn+axThwhkO6xpkfxCZaxyQc0MzeS+nHKtSCvBhBsIUC/CfKF9qplF11VeTFr7D/WESaLM7IxDBijaln47n4Rvikxok4HiulBJdNBH58+Ge1bRl7gM2ksGF0d83ikojR2lJUc7TDdCr32vX1IvPc70MBOR4G/OKsW5kfNbozjBcTb84QHIw5c7hYJJUkcqIrcUD07OFLiw/ofJH9yQ0auG+Uqo9NfZcoQnM 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 2024/10/16 15:49, Kefeng Wang wrote: > > > On 2024/10/10 17:58, Baolin Wang wrote: >> Hi, >> >> This RFC patch series attempts to support large folios for tmpfs. >> >> 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'. >> >> Add a new huge option 'write_size' to support large folio allocation >> based >> on the write size for tmpfs write and fallocate paths. So the huge pages >> allocation strategy for tmpfs is that, if the 'huge=' option >> (huge=always/within_size/advise) is enabled or the 'shmem_enabled' option >> is 'force', it need just allow PMD sized THP to keep backward >> compatibility >> for tmpfs. While 'huge=' option is disabled (huge=never) or the >> 'shmem_enabled' >> option is 'deny', it will still disable any large folio allocations. Only >> when the 'huge=' option is 'write_size', it will allow allocating large >> folios based on the write size. >> >> And I think the 'huge=write_size' option should be the default behavior >> for tmpfs in future. > > Could we avoid new huge= option for tmpfs, maybe support other orders > for both read/write/fallocate if mount with huge? Um, I am afraid not, as that would break the 'huge=' compatibility. That is to say, users still want PMD-sized huge pages if 'huge=always'.