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 80458CF6498 for ; Mon, 30 Sep 2024 03:15:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC0646B0105; Sun, 29 Sep 2024 23:15:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CFA186B0108; Sun, 29 Sep 2024 23:15:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9C5C6B0106; Sun, 29 Sep 2024 23:15:23 -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 990C780009 for ; Sun, 29 Sep 2024 23:15:23 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 48A8D1C5040 for ; Mon, 30 Sep 2024 03:15:23 +0000 (UTC) X-FDA: 82619938926.12.6B96757 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf22.hostedemail.com (Postfix) with ESMTP id 06FE3C0010 for ; Mon, 30 Sep 2024 03:15:19 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf22.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727665983; 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=Teh9T9nE9MihB1cX2UhygkHcS+8iRSonaFY0WaeD4P8=; b=aBrPuq3HvzdOhWaLmb+Vgt8m8ZWO0Dfx5CpGjNvP2pY5eGTFqOPdEXe+qHL4z4CNypHty6 6U33xdPUljnpJGEAAonrywkWOlIGubaCwyczOpo6c31LXWTrz0zDDqZoCoR+IhPRtzaVH9 awCPEKjpnvWIgD5J0mivvFSxedcfZW8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727665983; a=rsa-sha256; cv=none; b=djjklujERo1LuTh5gdbYw9IjgyohE6uBKH5usrHLUN9+cdanYzirdBm/9u9/Q4G3YpX0X+ lFq5TyZqRldCZ/wCuEqbqCqCUEIJx5yfMP7w3W9bQ3GTaBQ34CJnP6j6RghOmTe1gAsaYf qeu03S4ghZ68IecU/yWF5QfedxDTbb8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf22.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4XH5ls07p2z20plH; Mon, 30 Sep 2024 11:14:49 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 6C1141400CB; Mon, 30 Sep 2024 11:15:15 +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 11:15:14 +0800 Message-ID: <2769e603-d35e-4f3e-83cf-509127b1797e@huawei.com> Date: Mon, 30 Sep 2024 11:15:14 +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> <8c5d01b2-f070-4395-aa72-5ad56d6423e5@huawei.com> <314f1320-43fd-45d5-a80c-b8ea90ae4b1b@linux.alibaba.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: <314f1320-43fd-45d5-a80c-b8ea90ae4b1b@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: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 06FE3C0010 X-Stat-Signature: apybj4f849a9nhtomyk71cp3uy31daan X-Rspam-User: X-HE-Tag: 1727666119-212798 X-HE-Meta: U2FsdGVkX19gPTD5D/7m5ahY73q195ZZvmWoTqFMclEmhlu3zogY76MEm1kHRAXNAt8sbfh2XoCq1KOO5aXJyL0xDqrMnKSZw7+lup/+H90k/CylHJYmYWQ6Czb53gL+iglKLJ/QM8n2cO+3Lr2UuLGXKpC67KHT/d/FaiwD/EqKZq/AVFHVwwIZ3I+hJO269qLs0cB7CBuSRrewG8kr4jneQoUVKQtdGQMdkwwQ+1Ya0dqR6D+aD51YVHCOjPOYmD6WVEoB+Q95jkVb4i9eBfx4ofUXQuIS/uCtxCXgb510+GyNH7PyJegBjich5keg69FxGt8fjXT3HqtPCPL/wFJyJFY5kZzsWCkkhrObKufM1b0cPX1nduUPwMJfmxvFjHlS+TywUwtpEYiQh2fa+dYYoSSfTt7rleKZIdKfxhN9YHYnDS0RrM5RdPuF2TSOEXLnoYB0CwK2dDaQ6qI+dW0XrWZad6eY2I0Std6AVA4gsTO7VPzbmNXEWM6tuEgkLn42ZUvcZxRwlJg9B6eA/sBBtw+DhnHA3kHXcHxti3bXVd7tHlQG8jBoGMSVDTkPwI/VH0XzyaKVzKbSZUM7Ek3qmevG7CVjtWdv+0Iq35LoU9vjHE5DkNcbpDGUb5uK3NEwkBLcMpJaRrgL5Fzbd34JbgP/WQ35pp4uAYPCLtY8QZXRTaMqKuOs4o7AmJwa3nlgkie3n/znGC/KT6hBcelzmaGW2ysXra5GL4jZcUVpmi64DmMfP2x/Vnk46mBhIiJ0ZBswMJ36z4vNZw3YmFQ5LHLs6r9UClx6z+gntl4+7618xKLtiXeYv4f1ge85LVZlHTqkc+lX+RBXntQ8rZ7ebzKJrghijJ5QrjfYStl5FPzgSODDWmRVNY3h4apAEtMJwQ1wW4X8KKHSS97VvNpyBR6VbPts359q7Ik1GJDU6+/dUyqKrIzbLCSy+Xv6tZ42xhLSLOLHjDLtuCH /ihHF/Nn pnjx9gKfmJYwNbE6HoDwpYsTewymSqsgTOHDLonHFRpx3Vbq2Kncm1YFD2XPqCJNh/7IntDQB7MYz7NmQk/hu4bx0QCLkVReMpuue0LJiC50KW53l0wcT+rlmEJ++GBBmL//bThQcRMtu+AZVxFUzvj/SpagEhRFvDPunmVDLspL1M/ark2resmQ0USSdz56ZLA6U 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:52, Baolin Wang wrote: > > > On 2024/9/30 10:30, Kefeng Wang wrote: >> >> >> 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]. Forget to mention, we still need to check sbinfo->huge, if mount with huge=never, but we fault in large chunk, write is slower than without 9aac777aaf94, the above changes or my patch could fix it. >>> >>> 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 > > Cool. Thanks. > >> 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. > > Yes, but as Hugh mentioned before, the options 'force' and 'deny' are > rather testing artifacts from the old ages. So I suspect if the 'deny' > option will be set in the real products, that means do we really need > consider this case too much? OK, so maybe just update the document.