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 0EA96CDE00B for ; Thu, 26 Sep 2024 14:21:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C9556B0096; Thu, 26 Sep 2024 10:21:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 679B46B0098; Thu, 26 Sep 2024 10:21:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5691E6B0099; Thu, 26 Sep 2024 10:21:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3FB9F6B0096 for ; Thu, 26 Sep 2024 10:21:04 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D54F841763 for ; Thu, 26 Sep 2024 14:21:03 +0000 (UTC) X-FDA: 82607101206.28.413D440 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf11.hostedemail.com (Postfix) with ESMTP id BA53E4001C for ; Thu, 26 Sep 2024 14:21:00 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727360425; a=rsa-sha256; cv=none; b=iktnyFIJO5r2Ckemqkra7K8l6fwezEU9Wm9eoRpNMYoeMjs4Q3Obinjn3+QR4fEhLD7pp6 zfsggJyQC3uWUSZy9ZPu7Iged6CIRIDaWBxATs3BTts77A9BBoEQHHv11oiEfuENyTKhBa vY79bUtbNHWiZ+xSFfqEeyGY5RQNOwk= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 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=1727360425; 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=zZZgpil4vrk0I64Cz7uPr1i9j73JTDZBAFI2iCsE1rk=; b=BiYQJDnI0Qtv1vK+B/IZr2QGgnTgjzyTRdmRpys98Aar18lPaH2LlXqUX/Ys8hJ+1XJZlB paI0CBspTXiN0IsDALxQlUhyP6/0ypL7ohwwaoVidSYOberOmf3OELSaVkw4r4NXcrMaOj BkLIODnzz+T8HhyOwNNaD892Kn1HIfI= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4XDwgd6kJGzfcf0; Thu, 26 Sep 2024 22:18:37 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id A3A73180087; Thu, 26 Sep 2024 22:20:55 +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; Thu, 26 Sep 2024 22:20:55 +0800 Message-ID: <9a420cea-b0c0-4c25-8c31-0eb2e2f33549@huawei.com> Date: Thu, 26 Sep 2024 22:20:54 +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 , "Pankaj Raghav (Samsung)" CC: 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> 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: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspam-User: X-Rspamd-Queue-Id: BA53E4001C X-Rspamd-Server: rspam01 X-Stat-Signature: a73a6rd1kfnbm55qi8oxxibiyfnxwmba X-HE-Tag: 1727360460-224924 X-HE-Meta: U2FsdGVkX18bmc3jEJI1lSnggpM0zVMuWaFt0oIIF37Xt5OTZXySMtT5cAZFHzIazoFVqS5yxtZSaqIOHegAUS9hGSSYAL49iaVie/VEkrTgFtyOd4PtrZ2cN6syN/iLLIrsr8j9zZPZM3Sudfw7l4idipcIMCbuOWLKYTlqFd9/NRhmDQ0Rk3azWiUcfFHmkF7QyQbwxw3jaVdDbQIFrHtOrN4XFR80Xwua+WLoEbLz2yYR+5loaWRp06BB6ZPqffylBX4VeKqL9HKqKuqN1MDyJjpckrRreVsNyJ6W8HtPqL05dfY1Z2nC/dNtOB9jPH/GAZrKdVomi6EH9Bl7yXn0bL+ajM+R/Bep1MOFFKqwTRDgb6mZo6Mn7P6mB1ZuWll6TAz4k7C6q5m+Uf1+Yk/o0TJgRKfbR49K892xInOXl3YHMWJDhmqoEY0lkhNvIHiOKl9DilWnM5uWgTyjYiqXGCA57rva7q36IUf9BmkfDFZ01kQlFJA20ASHXfwdiOQnupGgOxlNmJbINSyz6Z/N4EUCYSreCH3MyVgRAyvD3oF0sDVlohLLBie1OYtqzGMxpyltX7PirvWNgqz2apvuYvFnNENryr8twwA/fwyn652/1LUEsZ4PQMDpNaPayXQsA7WXpAnWTOFiiTwYSauRd+kSS0R77Evm4ZfiReTWh6kbt9B5RvFWJ69LI2+ZMQ3hJ84MQ4EiZdtCm95IFGYi4JTstyyqSGhVBqybGGOZhGwbLKLidU9s4QJjAY+rtm1KKm9DenXSoHOjYZDNj7DxrO0pVvbkEIoFYUumkt8kO6uxeWFxsav5lbVpqyysoLil6HLJdzJATqImi+vmIsaX+wKPzYfdR4heLc2XXzomkg8Fl26WMlGAx7nLA565Z90wnYcDWWZIFacwV+wDMMmGSWTaBeEbCsYkCAtmMFi5b1F3tDixCRK0tKjcHPTufA0CGFPjFGivpGCcOk2 NrIstKQo MHhX0Tr2ggBYnhSu714UkDJQWUADVGDwkhVczoVjJfAbsdaFiEY49j/X587xSHI1yU2MijB8rkF1yIW8+vYCl+y2A8cHBwPxGORxxCugfQ/5Zrl3AptvNjjBkcIf/KFbspmJAWyS2AVwH1GX8OE13pqeDKyXPItbeC/WSxvB8pajsCVQ= 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 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); > But it can't solve all issue, eg, mount with huge = SHMEM_HUGE_WITHIN_SIZE, or mount with SHMEM_HUGE_ALWAYS + runtime SHMEM_HUGE_DENY and the above change will break mount with SHMEM_HUGE_NEVER + runtime SHMEM_HUGE_FORCE