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 4D8ACCF6491 for ; Mon, 30 Sep 2024 06:48:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD31A80009; Mon, 30 Sep 2024 02:48:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C81BE8D0002; Mon, 30 Sep 2024 02:48:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B233880009; Mon, 30 Sep 2024 02:48:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 91D568D0002 for ; Mon, 30 Sep 2024 02:48:56 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0E9E11C6DE9 for ; Mon, 30 Sep 2024 06:48:56 +0000 (UTC) X-FDA: 82620477072.02.0CCB0C3 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) by imf14.hostedemail.com (Postfix) with ESMTP id 808B4100008 for ; Mon, 30 Sep 2024 06:48:53 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=WCKZ8mKt; spf=pass (imf14.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.113 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727678809; 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:dkim-signature; bh=5Ik9T3maKQjieQebIpIXmvBXAB1bVuJfMCqq6dJICpU=; b=yJ18Z8OLRuwlVYpYX0iWMuukfW0kmOTaMKRVfbA/BK+6/5YLQ6BKu21WGGRSFq0FNc37DT 9/wbE3gliXjD+ujhD2jTJ38lHU9pKGhfj2MkhOWzHuecATllFoip2/f0QIDJuwzi1pV5Yu qOmMJz/wIkc9zjCrwVniX5fdc6Wgoio= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727678809; a=rsa-sha256; cv=none; b=TpycXkI4Mc9y5jBI0v69kepHLVaq3FbkS2NMSg2iq3uFJmCGJ+iQIFkOPifHu4AgJL22Gx Ui8KyEZq1TbUd5F68zkUOIYFamlFUdhC7AK9IHW8c+pwOlYY5OJl1uqJuSYlPxhLkkfYUq 0Pd98+pw+S2nDd8DD+Uk7lLWrnxtIPY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=WCKZ8mKt; spf=pass (imf14.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.113 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1727678930; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=5Ik9T3maKQjieQebIpIXmvBXAB1bVuJfMCqq6dJICpU=; b=WCKZ8mKt2YMEKoJSLzH6sF3UxqxN03WS6iywfDZiscSGkwjp3xs3NCKIdJgyWm28XOGiQwR62x1nc/lDx0BT5MX8lzPHF3FLXFNNCzYHeztQ035vq4pL00aCIDGrEbFoYdrENkKrZouMDq8oEtEWUA4cHFgujLTrv47ERMrPjo0= Received: from 30.74.144.111(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WFz-QbS_1727678927) by smtp.aliyun-inc.com; Mon, 30 Sep 2024 14:48:48 +0800 Message-ID: <72170ff2-f23d-4246-abe8-15270ad1bb39@linux.alibaba.com> Date: Mon, 30 Sep 2024 14:48:46 +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: Kefeng Wang , Matthew Wilcox , "Pankaj Raghav (Samsung)" Cc: Andrew Morton , Hugh Dickins , Alexander Viro , Christian Brauner , Jan Kara , Anna Schumaker , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org 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> <2769e603-d35e-4f3e-83cf-509127b1797e@huawei.com> From: Baolin Wang In-Reply-To: <2769e603-d35e-4f3e-83cf-509127b1797e@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 808B4100008 X-Stat-Signature: m8o8m7ibn4xh9go1gmngeti4669ydcfk X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727678933-253764 X-HE-Meta: U2FsdGVkX1+L4Lo/IILwUkVKZ7qjT6LdmImjMNXLa7uuLBhX/byozurt0k5XB4DJNPv/pW90K0okGnpTZSm4RAOBN2mKDtSb3U8Ww9WqmFSHU4am9BrzL1x8l8yqEr2U2b24Y4LDWuniuLo/tT+xwXi5FFZHFZWXBAidClUYxypM8k2/dQNDo7FZos7a7/+11oEmmWxgAZFR9dOSJRJY84EH3a7xZ5wYT2fZMotjd8oxBo3WwmYdGPySPk0LEorC2scxZokr9wqUCzECbKDdQNwc3f+VIV0erw9pCOhJYtAOvMt0TwNnSRZvBONAglnmLJ+yd9u4IAurRov6ZdoGc2zZyCjCUSgoCZpgV1pv94H/oUaprdRcCeeqzFVgL8qSWtcaP3e0gOsw3ghh92qhYdFzfSs0R2Whwer3sZ9SpSxsIqHWvRcqA0D+Je3ppE1MnO/xO0iEeqbHkRPsgYIDQ5aIwZSrTyiq8yzqFtQ+Ir2prwRv0khaiG84c0BmWM2xtRgUgnlxjFGqGnygaC57Q+YM32Uv/bOD74G8Y5g1QZbonmWoP2lVR3ROp3lR+HO0gLdTB7IFgr6h6ngTW2kx1cPGZeOY70BeE4Wi1oq+e5Hg5jO05aWnQawK509NzonyQnKPzjKMBIdX9qwo6mw0YaBVl8OY3eMEI5LCHrYepjR1UYQdikjv8rdpAJqMZAnOlM9+rnDBqxCc+JsHFAWyXnsUlkwjUqy0/13Ik3mhh/a8u9Pfm1QOLdwvvW/hTKvFRMi+DkwKF7CYlo26Uz00koOZOxmuNuizu20cyxKC4P038UWPP/EMPwtbHT6e/W72yikNS7PMwspgbjd/0Rmww/0MrVElN/3vkjxiAFJMz9VJC2K5n6D2kS7LCBtFOJMFbgR4mx4zZTXjDRivTeGxWrhtQCX+nmYCY0wPPDiAN/CxSYwDLDo+b2j/TqQAHIv73KFgsy4eSRQbVPEE71y VyGlzsvy N0BRz8wtefVUCn+bjPBkB6hgaanMaBQLnf1a0coq7WyWdxlIP9f2+TsmjRAIOqh7uJhx90LVKO8JV4BtVlMuZfnglCVz4niIiccbBlyLHDFiz0rK/cQMff9WNMgAlBuuWsFZo3WG6KjA2FMMlf7653ABu2FEwpY93Bt2Lz5W6BYZ1nLjCtq4QzLOd0EeOOhUID1G2Q3w5V46ayY1krVDvzLTLu6Og3mEQ2l0yDmsn1Nf2ZfnPhGExDCCQQwTm8lU/5dSogbnq6PpUpCacKCbAj5sFrg== 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 11:15, Kefeng Wang wrote: > > > 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. My patch will allow allocating large folios in the tmpfs write and fallocate paths though the 'huge' option is 'never'. My initial thought for supporting large folio is that, if the 'huge' option is enabled, to maintain backward compatibility, we only allow 2M PMD-sized order allocations. If the 'huge' option is disabled(huge=never), we still allow large folio allocations based on the write length. Another choice is to allow the different sized large folio allocation based on the write length when the 'huge' option is enabled, rather than just the 2M PMD sized. But will force the huge orders off if 'huge' option is disabled. Still need some discussions to determine which method is preferable.