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 C499FD2126D for ; Thu, 17 Oct 2024 09:53:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 582506B009A; Thu, 17 Oct 2024 05:53:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 532F96B009E; Thu, 17 Oct 2024 05:53:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FAAF6B00A0; Thu, 17 Oct 2024 05:53:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1F1E76B009A for ; Thu, 17 Oct 2024 05:53:06 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B5C401C6D57 for ; Thu, 17 Oct 2024 09:52:53 +0000 (UTC) X-FDA: 82682630520.05.8994B66 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by imf08.hostedemail.com (Postfix) with ESMTP id 12E5C160020 for ; Thu, 17 Oct 2024 09:52:55 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=Tw4Q0Maa; spf=pass (imf08.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 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=1729158639; 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=ofxGs6YeS3jUTLuk1L96YlB7Ior4G7eilHwR7pw/b9Q=; b=8ORWbypHWEfArO7HJF14JPbwmMhSFDLglg98t6zhPtFJ8noZV6JUQrVE0cn7yH8gSGFEk/ kLpiB97eXh5HsJAtvZG9lInyGs7EZbBslFsTAkzKAdSv14I/bHan5o1r+pjWJdcO4WuBTL 7FSgRsTjz0fX3V6RZw743SJVJnmReqk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729158639; a=rsa-sha256; cv=none; b=W5LBQyn7r0XoUFWJbQdbnYqYz4I/gvRimPFAoAh4+NDYKIkPHbRKtHPInWhrsVG5odUDfa b4BDQLGQA/chMYxaUgn3azaO6E7CjqttljGxnSWJhLOjeDjNzQCSVaWX5G2UoIxsPlIHL3 HLOg3GZtt22yTXWAkw854x/3SY3NZew= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=Tw4Q0Maa; spf=pass (imf08.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 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=1729158779; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=ofxGs6YeS3jUTLuk1L96YlB7Ior4G7eilHwR7pw/b9Q=; b=Tw4Q0Maaj2ycUxfTB1ZlZI1C4BFCc/osgJyLoLwQnbn+kUCmlHiuOoeT3deD18JeIfunadd6YXsC5L7I/2mhucSOa3bgAtBvdhhlIhHk4CwBjeuVfXK7IgnNG+k1VXc1Lu6d50YPqagkJSlj+r4Fb/IfRuRBgujE4rkRVf0QavM= Received: from 30.74.144.140(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WHKPoqa_1729158776 cluster:ay36) by smtp.aliyun-inc.com; Thu, 17 Oct 2024 17:52:58 +0800 Message-ID: Date: Thu, 17 Oct 2024 17:52:56 +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> <584662fb-cb1f-4b2c-9075-f70d31473c9d@linux.alibaba.com> <6457b1fa-9afd-4552-ae5b-3a0379bcc3e5@huawei.com> From: Baolin Wang In-Reply-To: <6457b1fa-9afd-4552-ae5b-3a0379bcc3e5@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 12E5C160020 X-Stat-Signature: un894wasxtrm3quq5rk5rdhprfqrp8jy X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729158775-143927 X-HE-Meta: U2FsdGVkX1/CVkrUfo0zNXvFcvBgMUgPBZ/iIEwNQj/iTmcUXxyVQmZmt04ijV/h321yh34AfCid6E0R0pYw/2v8g2ck2TfSDFJYxMIOhv6fQyTA3AHFOzVj4d+PpOn7NhPmbm4ldoL4EU7NPPNN3qnOs6E1GfUz296uFgGQmMSDuIEQXBZpChHADA/E6YF7daxF/uR2gDhUGKpClGJFp38Je3xFe6Vz+t0zO/3EPNlpmA3i+gAbm4VWvAac8QzhlGoHZMRL33dDEhbTLn5dQgOELzKyMXV2dlmMhKEje8h9q1f5mdQehn4fcPlz43N0a0U5mABfX+wQM0UaWp8dK0iOQ9pT2tyr4Ik6EGJfQspsqNO1TVCEW8KiluSHQxgqRLzT2fh39bCfIPV6/gWTV2URLxP4g81U7drBDktMD5L01rWBOSxNx+c3xuHyahgbSyn2HZSFa+LyAYv5WlD2fueaXuA2lQhpTqzp9yeKthHy8CctBh6+A740aQAtQnyFt74SLA0A/hWgcUx60ndrMRpfL0DCHRJsWBNKwPMa6RkQzOAFtvd3ef1oS8vo7/WnVdA396kKHNQpaQ6ah0tdtog//J/+k+m/Ui4zm3IcAB63FIAV+gw7Kl62mgUIj+LeI3aLJ8JMBxi2kZl8YuD/IhtYgVeuZl36NJ/Jv8FlMe5i6yX7tgdtvWa0fGZirJzdwjW6/iN48cbynC9thZnAWrVeJyZOrjvERf6nCOjecjShmV8nk5zFFuYtMbYdFQyaRBFJ6XhY3Wu/XjUzyYn2DxwlSIFdif0r49GpbhaPnraD/4Xnx9s4z35x0triiXE760vSEkEz+3fPyvHU9TLaC7mByu17Z4/ynCiYZU0XGduyzLQeZ8ghxMLyuSOoKhgzQDZx+0Kc/QM2qxqWzVqCb5XfozNOUAg3vEXlLRSqv4lYRn++7RRRMiMkTk9akkECe5jidJI5p7QNOVo96O5 RZnwfB6s uH8aP/RqF9EpZhLJSCyOoaTs3WQJ16wQSTkZWQaVY11qwDiiuyraES8Me565kEIcdnAXtBmsOrBPAgbjjolwTVeecjWbgcciR1kV80DGK2WcAgl98Lr4sIjFERtLbX5tNE3bWP/DsuUZsJ29hAZQl5uNsKdr/oNIPhweIGdeyQCSBtqA7Lr0biWQjy87rd9P7VotPMehJNGs74hOAOEwo0hv1JMzGLsAt8DEJg/WXxiLQ+a1X+vqTBhZ4UAsYn994HvtuQsang49/ybkMjX+d7u4AQS/LHwhqtJtvkuZHeeEM1Kjede91+7OluFHblIZZR+ZaOJ18G/6AjS3lSR9PrV1D4w== 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 21:45, Kefeng Wang wrote: > > > On 2024/10/16 17:29, Baolin Wang wrote: >> >> >> 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'. > > Yes, compatibility maybe an issue, but only write/fallocate side support > large folio is a little strange, maybe a new mode to support both read/ > write/fallocate? Because tmpfs read() will not allocate folios for tmpfs holes, and will use ZERO_PAGE instead. If the shmem folios are swapped out, and now we will always swapin base page, which is another story... For tmpfs mmap() read, we do not have a length to indicate how large the folio should be allocated. Moreover, we have decided against adding any mTHP interfaces for tmpfs in the previous discussion[1]. [1] https://lore.kernel.org/all/ZvVRiJYfaXD645Nh@casper.infradead.org/