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 8DDECCF259C for ; Mon, 14 Oct 2024 02:36:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F377F6B0082; Sun, 13 Oct 2024 22:36:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EE7806B0083; Sun, 13 Oct 2024 22:36:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAFF96B0085; Sun, 13 Oct 2024 22:36:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BC0566B0082 for ; Sun, 13 Oct 2024 22:36:45 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9807340AF0 for ; Mon, 14 Oct 2024 02:36:40 +0000 (UTC) X-FDA: 82670644644.02.E0D67A4 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf30.hostedemail.com (Postfix) with ESMTP id F106A80002 for ; Mon, 14 Oct 2024 02:36:31 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 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=1728873247; 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=ZpdhFXu+L/kTwzBYe3xfm6gli+ooViKEtc4ZOX3wl8I=; b=SvIz1+OBAhMChDi4KZSzfV3vWv1sLCvvV75qUhxCAmrzDaZphbdLTx4JBhgemGt2LMFTr6 BCFa9SDr1C6r8mOqOESjxKrKggYMNbYvVXM4yrSxeJVC3xtTpEUv2hu91sGGINpN0bCb1W 7BZ5bRBtFdNHGWGQb4nU3bAasgGaS8I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728873247; a=rsa-sha256; cv=none; b=7xHr49/bZDcdeOBCNCMIcx5eEele4aePrDnK7xyQwL+aILwvnOIzXmpxaxZ4azVAqluT4O S8efMeq4t75LudnGgdqE+IwKPsCU/WDIr0o834g80e3DNLAoMzMVrsdmMeVufSgrEWQOWK Tg+ZC8EuyEQxtWSIC3qYEHA7QhQxiV0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4XRh8W5jTbz1HHLn; Mon, 14 Oct 2024 10:32:27 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 94D571A016C; Mon, 14 Oct 2024 10:36:38 +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, 14 Oct 2024 10:36:38 +0800 Message-ID: Date: Mon, 14 Oct 2024 10:36:37 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] tmpfs: don't enable large folios if not supported To: Baolin Wang , Andrew Morton , Hugh Dickins CC: Alexander Viro , Christian Brauner , Jan Kara , Matthew Wilcox , , , David Hildenbrand References: <20240920143654.1008756-1-wangkefeng.wang@huawei.com> <20241011065919.2086827-1-wangkefeng.wang@huawei.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: 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: rspam07 X-Rspamd-Queue-Id: F106A80002 X-Stat-Signature: fnech5gcctf5z7wj5f454dhy7t5y9qin X-Rspam-User: X-HE-Tag: 1728873391-834715 X-HE-Meta: U2FsdGVkX19XtdgUTThXGdOPKHaBYGgP6mfQXmBaf0zmxQIH0d+2FGu0nO+xyPbU+tpdtAcTv4pWH+QkMOtsX0je6unl+sKeNC5Uj3Szpt32v0WdKWkaYB/RFbb9mzJdgzqHcvzZ2q9bSpd4S78NP3gMbfJHUOVl4g+Y/JqCJLoz4r67TVwz+g6b+Gl1kdgAS/gWRCPxg3lbGpXuzf0syStgaXafRC0XhFDE3P5mTzEzEq/30vwUGAzLicAC4RRef2IFjvFt8B3MCQz2QWLK8k8iYqWNf7W0hSGq8L1sH7XZGdEJVOLiz3+y+uGMM2dcB6USFqtfpPs7jUWh5OSjG+svkVHvCw7eTLxDkWiB9x3ByZNwiXahfkIcIrew2dJSwL88UN7/2MI0hugoZsfAzvVfuok9yrRZzrl/IItlbo1+sV18nhX1v9MxjOLZn/7R2vJ8s6K+Oy+fAyhFIEEmxMClUNdqVcAvPc4ibkzwooGQL+k5Ifulf7sWUq4i27QCeijHQoXDsNvDw33dWCxBAjJzUc/uMCmAKhKA7BwbasyB9uTkhwyTB79AJ0HCaqpuGLFiM75gWbp0mMOEqCfX5YN2ykMJ9P5Eo7J5M+36ah8pu73H2BzOzF0rlRgKZNWk/khct1EPWj48tfxovcgIa81GqOvfXXQF7KRQVNfmYqh2jEgSqRzLFKUfMlaDWCz1+U5HdMxW/HCvQz7IPmIl7qWNE4sm72545b0bsU2AJa4veBOnguz7M2Db5iiKGgIxj8/AVL2F+nk+ZnuLuIkiHUayZwXZTSp7gAZOi0ZPl3M3AsXhs+TzEXdAzlEVCFawBJlDKFcDYgpZ508ZQnmgRap5jH+1+EKrJOI4jBbgv0k4Flmy9zFPDNbyJhMVPYHUh+TQL5YuyDX0BEJjVXbmd1BCsx1+91PRy1ebj6x4NbO7TNeZ8guCrLeP3lIZLKZNAf/rK2HVINg1jM9EXKB 7H7NxS2y +4T89g8QZy/JHw1qs/OzCX+uugg5CYv9peCRODO/pKAv7glBstez6MrwxdfCMrHEEfxTftXfjyqmQDVwHs04ni/ST/yijoDctaFC8wfqJ/VbevViUedBo/4ASFDFb0wUBiVeKSzvTtmjuHRC0fQVK0EoknAM/tO91uoGSjB43O1tslGOh1zL8ETwHK3H7LYRSC7vXq+ozogSc11tjhWdSrjQctQ== 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/12 11:59, Baolin Wang wrote: > > > On 2024/10/11 14:59, Kefeng Wang wrote: >> The tmpfs could support large folio, but there is some configurable >> options(mount options and runtime deny/force) to enable/disable large >> folio allocation, so there is a performance issue when perform write >> without large folio, the issue is similar to commit 4e527d5841e2 >> ("iomap: fault in smaller chunks for non-large folio mappings"). >> >> Don't call mapping_set_large_folios() in __shmem_get_inode() when >> large folio is disabled to fix it. >> >> Fixes: 9aac777aaf94 ("filemap: Convert generic_perform_write() to >> support large folios") >> Signed-off-by: Kefeng Wang >> --- >> >> v3: >> - don't enable large folio suppport in __shmem_get_inode() if disabled, >>    suggested by Matthew. >> >> v2: >> - Don't use IOCB flags >> >>   mm/shmem.c | 5 ++++- >>   1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/mm/shmem.c b/mm/shmem.c >> index 0a2f78c2b919..2b859ac4ddc5 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -2850,7 +2850,10 @@ 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 && shmem_huge != SHMEM_HUGE_DENY) || >> +        shmem_huge == SHMEM_HUGE_FORCE) >> +        mapping_set_large_folios(inode->i_mapping); > > IMHO, I'm still a little concerned about the 'shmem_huge' validation. > Since the 'shmem_huge' can be set at runtime, that means file mapping > with 'huge=always' option might miss the opportunity to allocate large > folios if the 'shmem_huge' is changed from 'deny' from 'always' at runtime. > > So I'd like to drop the 'shmem_huge' validation and add some comments to > indicate 'deny' and 'force' options are only for testing purpose and > performence issue should not be a problem in the real production > environments. No strange opinion, the previous version could cover the runtime deny/ force, but it is a little complicated as Matthew pointed, if no other comments, I will drop the shmem_huge check. > > That's just my 2 cents:)