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 A53D0CF6498 for ; Mon, 30 Sep 2024 02:31:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33CC06B019F; Sun, 29 Sep 2024 22:31:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EC8C6B01A5; Sun, 29 Sep 2024 22:31:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DB246B01A6; Sun, 29 Sep 2024 22:31:06 -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 014056B019F for ; Sun, 29 Sep 2024 22:31:05 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 13F971C4F94 for ; Mon, 30 Sep 2024 02:31:05 +0000 (UTC) X-FDA: 82619827290.15.AAF3018 Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf16.hostedemail.com (Postfix) with ESMTP id 1A190180002 for ; Mon, 30 Sep 2024 02:31:01 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727663296; 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=g3nuBYx0hkvH3+BMGrd5jUj226y59YnJOWQVecrqa/A=; b=myahPKwxkasawOIuvsP9Lakt9KNIQeBnK3iqs6CI9XpdFaqfSQRB4TJ7ZhRls58iU751Gg XsuFKDkE3i53U/F1hTQpjmS+3rTjSVAdGB7SZYWlRuxcT5MMGRCjSbPDmDGxTK7TLs3Ok3 TlL6C6RhIPb9ytJEwauhh8r+kLCNuQ8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727663296; a=rsa-sha256; cv=none; b=2RqYVWrltw+fpHeFQM44gAhPFsJU53kAEEhB0hQKAFTtNWAbGwKbx4cMIQrvShp4pT21v3 zn1CkiHUqE2E6/04cLJpXNw7wKw+FWw5zzMPrcDChdP2Vyw3z3ryTkOI3wO9ncnqy7/slN /1G8wL9yeIu2hd5zeKwLg1U7XBBITpI= Received: from mail.maildlp.com (unknown [172.19.88.234]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4XH4mC1zVZz1SBK2; Mon, 30 Sep 2024 10:30:03 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 303171401E9; Mon, 30 Sep 2024 10:30:57 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 30 Sep 2024 10:30:56 +0800 Message-ID: <8c5d01b2-f070-4395-aa72-5ad56d6423e5@huawei.com> Date: Mon, 30 Sep 2024 10:30:56 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tmpfs: fault in smaller chunks if large folio allocation not allowed To: Baolin Wang , Matthew Wilcox , "Pankaj Raghav (Samsung)" CC: Andrew Morton , Hugh Dickins , Alexander Viro , Christian Brauner , Jan Kara , Anna Schumaker , , References: <20240914140613.2334139-1-wangkefeng.wang@huawei.com> <20240920143654.1008756-1-wangkefeng.wang@huawei.com> <1d4f98aa-f57d-4801-8510-5c44e027c4e4@huawei.com> <1e5357de-3356-4ae7-bc69-b50edca3852b@linux.alibaba.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: <1e5357de-3356-4ae7-bc69-b50edca3852b@linux.alibaba.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1A190180002 X-Stat-Signature: 7mqmqwaun5bomeh97qansskt764tt8s4 X-Rspam-User: X-HE-Tag: 1727663461-638457 X-HE-Meta: U2FsdGVkX1/xCE+gh7vkkc4Mmsc3VgjYrW4wYOUapRxZ/v+ghbQwouJ1cihEPSfbHQZawTUBogdp8zJyA+WA1b25wq4zEQPUZHvvkhZE+lCkEs/36+Ntd82s2/xprPBZr93mKcAvh5NBSztcu0AKkdHV3Yaq8eEczDS1LmVE/y8rMT0ekapersewOhjWrkC79zGvnyedjDI1i0uIAXGQ0UXobXfH6zK1jYOxroX4VfViVcCjuvSXd3ZI+h7Dhg59zZjm2HORPCJoL4UkAL24D0LFHhSO1qnHpN6+3X/GkscJX/RbYCB4hy0ieQl1m2XbDEIuebtKnYCXILzSBOssQrJjrzekO38ESu10no1QbyAy8X/zZHAqCvUaUP+E75u2a7UWgQtrieUIiX2+LRyDb6MhNqf7FJf1b+SVUbyayUhbLQ+GBrHuxoqTwfuVUxfWjr36nscO5bxtOMZf1fM+2QHpteHZouGN0XV1XjetxtPVqrz3ZDqYUvqrenPq1XnCUrWKuIvEkMqatuC0XC/Pbxm9PT+UN/TGT0uV0jFz96gkvflSWS+zIvWa+NYy+q7KoKnS2oSz9c1SYiwu3hSIlipffO+lXJC5Vv7gn8Nu0BeIO1Q6vFxqCXpTT+u9IXd6u3vWsDRyFTFmwZE4SOOgO3Q8EjbPmvWWl/A/2AxPBTCMsJbZ2wRGzHcEFWY7D2gVOk/QaiHejMDCPcTBpbbOpDvcxbpgfQaLZ0U2SyP8j0sDvfJhf1LuP3r9O+odLLRGpLyINQrD5SMtGm6u/MkKEvNVJpuaW9ZnrAKOE1zCViGW3VCO/DQYPU4eKv2dfTqvvN9xVLkFbFx7f30TTpqLGj1nXGGlRYjoHGhMJRFc1vgjp+PAledAIkTunqXsa0YIZLHp3RRjd/AjMdf8SDu/53u9uWGwZeIFvBrTti5/QQmQRFmiD5RBzbAfPwbamDpGdw63iV/fvZlfecwDZpm gVPwOl1e A7KXbqj0AP6DU1iPVBAijhFFM17EtkXexUAMvIvEmNVKqDeTq3a/wBn+9fqEdK1bLnS1Nch7L9HcOADypbZWkhXvOL08YZ9AC99eGPFwK+XwEdAoYJo+poe5TzW1eXGE+ImMU4Q2YCx7LXwOfbQorDESZ3/hT6PRbIoqXgqmXB8cAcddHxSbAx0L2blKNXsk/mNrpbf9pBUHe2bnfnD9J+DK/Ir1PWUYf+lkYEReCRSMzbFU= 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/9/30 10:02, Baolin Wang wrote: > > > On 2024/9/26 21:52, Matthew Wilcox wrote: >> On Thu, Sep 26, 2024 at 10:38:34AM +0200, Pankaj Raghav (Samsung) wrote: >>>> So this is why I don't use mapping_set_folio_order_range() here, but >>>> correct me if I am wrong. >>> >>> Yeah, the inode is active here as the max folio size is decided based on >>> the write size, so probably mapping_set_folio_order_range() will not be >>> a safe option. >> >> You really are all making too much of this.  Here's the patch I think we >> need: >> >> +++ b/mm/shmem.c >> @@ -2831,7 +2831,8 @@ static struct inode *__shmem_get_inode(struct >> mnt_idmap *idmap, >>          cache_no_acl(inode); >>          if (sbinfo->noswap) >>                  mapping_set_unevictable(inode->i_mapping); >> -       mapping_set_large_folios(inode->i_mapping); >> +       if (sbinfo->huge) >> +               mapping_set_large_folios(inode->i_mapping); >> >>          switch (mode & S_IFMT) { >>          default: > > IMHO, we no longer need the the 'sbinfo->huge' validation after adding > support for large folios in the tmpfs write and fallocate paths [1]. > > Kefeng, can you try if the following RFC patch [1] can solve your > problem? Thanks. > (PS: I will revise the patch according to Matthew's suggestion) Sure, will try once I come back, but [1] won't solve the issue when set force/deny at runtime, eg, mount with always/within_size, but set deny when runtime, we still fault in large chunks, but we can't allocate large folio, the performance of write will be degradation. > > [1] https://lore.kernel.org/all/ > c03ec1cb1392332726ab265a3d826fe1c408c7e7.1727338549.git.baolin.wang@linux.alibaba.com/