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 981B2CF6498 for ; Mon, 30 Sep 2024 01:27:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 731306B016E; Sun, 29 Sep 2024 21:27:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E1EA6B0173; Sun, 29 Sep 2024 21:27:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55AB46B0171; Sun, 29 Sep 2024 21:27:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3760B6B016D for ; Sun, 29 Sep 2024 21:27:45 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 411278186F for ; Mon, 30 Sep 2024 01:27:44 +0000 (UTC) X-FDA: 82619667648.28.ACB0CFC Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by imf04.hostedemail.com (Postfix) with ESMTP id 97EC440007 for ; Mon, 30 Sep 2024 01:27:40 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727659569; a=rsa-sha256; cv=none; b=yQteTNHz/ZPpe7lrBR+VBcZYTZeSOMVTmJEOSsWkyJnbDA3NWwYWPUmIYZqGAqInp8pxoE nV9N9CzZyD046vnFe1JhR/gwGNYS0d94+WV2W2/sOxvhgraK9teLutrpQulrl0o3Zynr6m MStjEVVVNoeSeshcggKuqA+3uSRJCFE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.32 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=1727659569; 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=QjtP2SbTxYtsQ0AAR7CdE9HqdulFQOIYOzJ7lkM7cp8=; b=6tU8bbW2e6u8yMUVvp5AnBlZjvVrSHJMHnrb8vRa/Rqb+TLvgDXH66VUJ0/zRAaEsXC7tY L8DX4hgn+Vo70C8AJO4B+vhYyeh1sK659xYaE1O33cV0wB86yBpZMxXx04OtLaa8luF/Ma vNJN/cnaZP9eZd1k4UyP6KzB/1QEfLg= Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4XH3NB4QL4z1ymhF; Mon, 30 Sep 2024 09:27:38 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 101CF180041; Mon, 30 Sep 2024 09:27:36 +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 09:27:35 +0800 Message-ID: <579518dd-a04c-491b-9c46-0880fa9fdf9c@huawei.com> Date: Mon, 30 Sep 2024 09:27:34 +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: Matthew Wilcox CC: "Pankaj Raghav (Samsung)" , Andrew Morton , Hugh Dickins , Alexander Viro , Christian Brauner , Jan Kara , Anna Schumaker , , , Baolin Wang References: <20240914140613.2334139-1-wangkefeng.wang@huawei.com> <20240920143654.1008756-1-wangkefeng.wang@huawei.com> <1d4f98aa-f57d-4801-8510-5c44e027c4e4@huawei.com> <9a420cea-b0c0-4c25-8c31-0eb2e2f33549@huawei.com> Content-Language: en-US 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: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Queue-Id: 97EC440007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ki61pc3f58ezxx4n1xoapzn51nkhkcgz X-HE-Tag: 1727659660-470945 X-HE-Meta: U2FsdGVkX19FSD4Eea+GMzallBlFlbsEJ18DNQSDA4l/dUtgI8yu1MVPXA0c+aAnO7hzfQHhLOrDccgZrNE3asjmWvjVeKGDXZn8YobB7OSZHvYdeDcwZ2tu/AtstErsFMGqVb5Q9aPPVo0+Bs9k0lazw91+oksKC+qjB7uvEsZI1AjT5aSscBqz10w5XHjynUHPvDD7ai1UYgxC1Ku4tlu0pKQl/kOWwH2r2HttCW7Zrniy2pF9LlK5+4TyJ1yp7ghJmPJBcuMxpzyMKNbTJ+Q5lpQPIYB4cIRlNXCtNrGQCQb9k5TeR+LYYajOJFwiOequFPpQ7hxKx0jwM/XVsNNv8uTSc4+OOOYEQnmjkocIYqtrK2F2RSXfaB6w6c77f8iU7SE04pKh7A95qIlqBVzNjY/tyXbyG86oS0eWKOJqSBs+LhGrLn63Y6vLvM630DILjjwANgkAK6xypKcfscfottz6vcDmRN//TG+p6cJ5xKk62VY5/FishGPZPYgC2GqYYhmgNIpYMc9MtZqJkAhpu7x8tvc6zTijH/G+oHMXDx68+42kNj4xBJqVfPBWwSIOLmibcQr+bJ7v8hHauZKhCSM44dWn4di89xxRVKETcCahtTZXtuxAR70vXbncLM58x7zWylUUEq11wK5W5YvwYH9KcHLAKY1So1OusjqjefXV3mqkqv0183o09olh3P1vWQkylHxICfP1HCn7XJScgyIiHGFTDlibqk6+orDk+hKjXgzeIOg/wV1WXbIDVif9R2IqDOQ9d0MQbymCGZfPIDfzq2dgTUDB3mW0xkm8Qpqmo01fS9WsPxTVhT6rXSq8HkLUiFqh/kz/WF/t1BhOpRARotKYS6XcnDIDTzWC0UFmV2pktJQRZr97FpBpS+F8sazLfhRUEHfEncRDnS3DqIrcaUVobaBIphi5rX7Pg9r+zAe/xxTnYqcCYddU/4OOtyV2cSpkNC1ltgE 4gwDACaH rdQyaLfJOM4od7B0tTDAmjG+Tbd6bZ3wmssUtSgjKPYQrLddQbQRUMPATJqCQcK/ZDmghCiUTnscLvcIDq7CbxhvQTm/PCQWOKSMD5kP0ZEYLKwpWAcyiR5AqCROSpVN3gfzs7gnZXkmBztOOdefHomN0+P6tn5+0lL/rTijcGCCiPnk= 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/26 22:58, Matthew Wilcox wrote: > On Thu, Sep 26, 2024 at 10:20:54PM +0800, Kefeng 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: >>> >>> - mapping_set_large_folios(inode->i_mapping); >>> + if (sbinfo->huge) >>> + mapping_set_large_folios(inode->i_mapping); >> >> But it can't solve all issue, eg, >> mount with huge = SHMEM_HUGE_WITHIN_SIZE, or > > The page cache will not create folios which overhang the end of the file > by more than the minimum folio size for that mapping. So this is wrong. Sorry for the late, not very familiar with it, will test after back to the office in next few days. > >> mount with SHMEM_HUGE_ALWAYS + runtime SHMEM_HUGE_DENY > > That's a tweak to this patch, not a fundamental problem with it. > >> and the above change will break >> mount with SHMEM_HUGE_NEVER + runtime SHMEM_HUGE_FORCE > > Likewise. > But the SHMEM_HUGE_DENY/FORCE could be changed at runtime, I don't find a better way to fix, any more suggestion will be appreciate, thanks.