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 EE4CDCAC5B7 for ; Wed, 18 Sep 2024 03:55:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0319A6B0082; Tue, 17 Sep 2024 23:55:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F23576B0083; Tue, 17 Sep 2024 23:55:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEAA66B0085; Tue, 17 Sep 2024 23:55:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C020C6B0082 for ; Tue, 17 Sep 2024 23:55:51 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 743A740199 for ; Wed, 18 Sep 2024 03:55:51 +0000 (UTC) X-FDA: 82576495302.27.9382529 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf11.hostedemail.com (Postfix) with ESMTP id B8ED640006 for ; Wed, 18 Sep 2024 03:55:48 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 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=1726631692; a=rsa-sha256; cv=none; b=rV4lXeCTRwBCtnNHLJP4eUVngJR4f+vU7rJV0NbrtgenUu1IeR5VVe5H7bDG/hr2FGnuQc Y5zAe+2KIFExCdHlbE7cwl1ME3t46fDRmX/oWm3HygYyafjLjAIiiIRmdVaMWD77F3ztFo Q5Ty/gR/YR4RoMi2P/63nKi3Tk7obgw= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 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=1726631692; 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=P78SK9NSF5hl8+a0uss51reB8fXnq1v3T1ttsF9DfWg=; b=IDgzJTQ2/pNajavgfQiHsjwEZLuN4UIb/kuX5E/0bCZ9tWFZyvvfgYyM54bAqTnyUy6SsE J2EqeCZgJAeAs7el5ATY+XGHJqR5QvKj2V7rsVegajUP40b7sWbiPsVQ2BDF/4IqFItABg 1hPHoqqtzSmZK6cYjfRbP2PZBlJzZXQ= Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4X7lC82bpBzyQlM; Wed, 18 Sep 2024 11:54:28 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 16CF11402E0; Wed, 18 Sep 2024 11:55:44 +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; Wed, 18 Sep 2024 11:55:43 +0800 Message-ID: <1c8c7401-e68d-4636-923d-57bb31f33a3d@huawei.com> Date: Wed, 18 Sep 2024 11:55:42 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH -next] tmpfs: fault in smaller chunks if large folio allocation not allowed Content-Language: en-US To: Matthew Wilcox CC: Andrew Morton , Hugh Dickins , Alexander Viro , Christian Brauner , Jan Kara , Anna Schumaker , , References: <20240914140613.2334139-1-wangkefeng.wang@huawei.com> From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit 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-Stat-Signature: yae4p6roa9s9r7rcphnu5dum18sm57sm X-Rspamd-Queue-Id: B8ED640006 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1726631748-257746 X-HE-Meta: U2FsdGVkX19He6fvwKev7Jz4gHKdltC4MHNaKkWYd30Y2tR0hl7lAxGQn7prqlds9qrC3xUS5QGBWDqcAp1SplqQw4FgQvlGMYSC4NCkgBLlJszoQU/UPFuMBshvwzupXVmjUSwvykrXFhlcCfCdi4wrTcsnROi45YZmFPL3WpI2gCMgXs5OyWvcq0/kQXAHtoyaacIJx0bV8qT4+jKQUnn7bGKmzXGvmwJg7g+xD54fRaJS7agdmnVMMW7jXxggScWWvaaeqQp61HsOk6lEyoJIaS3WhA3QLyOcjpuKaPuuCWUWUN9eQMa/eXaG4RTwOA4kyN0Wo27voreGcPGFSBZFTOEBPd/KkMU/fpt/K92qDdyP7wbOft12+m8E/U8xOO0tGPFkvzao48vt7xbzZvg4o9TrqeY3ZhdF3eTBCOpM0B/zjs9LsuNe8lE5KgUkJYtIANinOiv1Ce++QIP+33fYNprNh3wequaedS+sx4raVG8ut7GT9AgqVuh4QkaAXmY17JH5MVf7rB2bkwl/6lNPfHE3qGD3wirK/YP21SUpEdS2ugGCSxxxLYw/RPNQKjItmbEyfItpTFKPUTNGzWt87BylcocGpU9TbmeY7p9EIBkfh9W84yFzdvmo+Fm0GfQ625nb+cQMjytoLmDvh4de54PNxLsGJPi1i1z4Mst1xIUpahxRavi+DfF/ZAk4UHyAfDuYc35QYEaOIJ8jqtJAZBAvDhvzW4BiU5CS5V49QY1ztK1RPukx+M9QcXKbM4HXDxjVygV6doapZQI3V/grRHb4xDeVh+dRlF/NcuNiaCBYQNORAXhPnBEordqgWrpX7U0/ecSEm54uPy+sPssEzV0o81LtgrNJz1yWW4Iq0HVlesYoZ4OoxJqeMK8uJTCulMaWA8RPmn9R2h5gVtF5HZ7h/rafrvxyRp2nY9Vt4YB2AaOotSswtiy0TabAw4BRHyRbLe+9f8PlrAT ncCWYQZI 9jPQyUZhPd66x5DG9oaRi3BK5jaNmfLhCO+2OjA9aufPm8tvjs4xdy+9vVJqkfikLKHqcTsjDJgA4CpQuzSByYqbV7HgC0guoHQWl8RFqQ9vW1HtsJPRpbm0asfUddMm/ifhpOdo155Uo6DMmYIDzYi3Cu7MdkjDc34dSx+LVSdjNeOc= 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/15 18:40, Matthew Wilcox wrote: > On Sat, Sep 14, 2024 at 10:06:13PM +0800, Kefeng Wang wrote: >> +++ b/mm/shmem.c >> @@ -3228,6 +3228,7 @@ static ssize_t shmem_file_write_iter(struct kiocb *iocb, struct iov_iter *from) >> { >> struct file *file = iocb->ki_filp; >> struct inode *inode = file->f_mapping->host; >> + pgoff_t index = iocb->ki_pos >> PAGE_SHIFT; >> ssize_t ret; >> >> inode_lock(inode); >> @@ -3240,6 +3241,10 @@ static ssize_t shmem_file_write_iter(struct kiocb *iocb, struct iov_iter *from) >> ret = file_update_time(file); >> if (ret) >> goto unlock; >> + >> + if (!shmem_allowable_huge_orders(inode, NULL, index, 0, false)) >> + iocb->ki_flags |= IOCB_NO_LARGE_CHUNK; > > Wouldn't it be better to call mapping_set_folio_order_range() so we > don't need this IOCB flag? > I think it before, but the comment of mapping_set_folio_order_range() said, "The filesystem should call this function in its inode constructor to indicate which base size (min) and maximum size (max) of folio the VFS can use to cache the contents of the file. This should only be used if the filesystem needs special handling of folio sizes (ie there is something the core cannot know). Do not tune it based on, eg, i_size. Context: This should not be called while the inode is active as it is non-atomic." and dynamically modify mappings without protect maybe a risk. Or adding a new __generic_perform_write() with a chunk_size argument to avoid to use a IOCB flag?