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 28118CF6498 for ; Mon, 30 Sep 2024 02:53:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B0378000F; Sun, 29 Sep 2024 22:53:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 460AE80009; Sun, 29 Sep 2024 22:53:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3010B8000F; Sun, 29 Sep 2024 22:53:02 -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 0DAC780009 for ; Sun, 29 Sep 2024 22:53:02 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8324A1A0683 for ; Mon, 30 Sep 2024 02:53:01 +0000 (UTC) X-FDA: 82619882562.11.0CEEBEC Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf13.hostedemail.com (Postfix) with ESMTP id 755F220005 for ; Mon, 30 Sep 2024 02:52:57 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=bNATaWJf; spf=pass (imf13.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 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=1727664655; 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=y9VI0Nw9VCS+z9O7n29X5Uf2tFeLAF5xMAQ7jImge6o=; b=UZg/CFAkRfqKxGUjydmH/GQzvRLcALdvVqODvCLO/ywh67/pt07CFaxg4IS21Za/Kn+YXD UWasT0PdVOOEKESJVvyMjdGzIWCKameN9mA4F4sagvjRP29jbskMf15mXNnREfa/BNw6gT oKxidvEtws4xxI89AOBcEPLsCvZ5hoI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727664655; a=rsa-sha256; cv=none; b=u84z/Mn9NVW1kINLoHi9dyhw2+MNWWRfXQWq/goBW9V9tP1SJSW4m+0WOC6UqF3cKVdSKP MG7g7RvtFnFNoxIuyec9FFcdMocT3q2yl9alQxI01k/5pG7FBtsUUSKFBinPZzDN4trt/F 8lo4V8OF740TjgWBIOiSGZ9NvkWwfXE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=bNATaWJf; spf=pass (imf13.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 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=1727664772; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=y9VI0Nw9VCS+z9O7n29X5Uf2tFeLAF5xMAQ7jImge6o=; b=bNATaWJfKUhA8p98B1O63YXpNh8aHU8upbhoQbMwd4Tw/Ho4EmxMFzXN11q8l5/hpNH8rAxoX54TewN1N4mgEfvYorPzdUpPFadNLXyN5qfXVA3jFeFEvZ/cYwXCvkWOJqUcdvx9lD9Y2dhelN7xMnKAbx4fUeTvrwy8jAZjIbc= Received: from 30.74.144.111(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WFxTQpD_1727664770) by smtp.aliyun-inc.com; Mon, 30 Sep 2024 10:52:51 +0800 Message-ID: <314f1320-43fd-45d5-a80c-b8ea90ae4b1b@linux.alibaba.com> Date: Mon, 30 Sep 2024 10:52:49 +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> From: Baolin Wang In-Reply-To: <8c5d01b2-f070-4395-aa72-5ad56d6423e5@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 755F220005 X-Stat-Signature: nga1t73rzjqh1efx57ur9tog3y8uubj3 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727664777-899974 X-HE-Meta: U2FsdGVkX1+/IODQeSjqBrdMyKXaeEp6wS0bKZiSBhTUsUUqrEGn6KxuxJ+KbLPNkw6+i/S6ZSpTCODDvbS8iHWb2NkV0khOJa1achqHa5V8sVFQDa18+PX0KmhjQLQouZhZ4howajN2WDPcqaY1+bbbqo2OVvCgnQ8meq9h3ex+/Ls8acKHfWmi2T+l8mZk+VXd7ydIXwhtPV44cM12N2/45qwWH7TCzgEg6rbwXtkZDfb79VCZSA9MsNwNUXP2T/h+DPr+sgY8bPE2sbDEedK3pdTUCXZV5/U0ub8FF8x23ORCp9G3JIzPgxEwMfFaiI3Ul4QorBeEnQgCizD0OjBnivigvUO+y1rUfXChlXCrspVPwyn/uYOQd08LkCCANxOt7f07A1c57zLcxf4aqmfPlumX8k7RFF0Dds4orIryUrxvzubvJ43A0Flla4EFcEA8egzo5AjhAy1XkKk3tOWg3dW/2EaaO9wJKTG8riBVgTpnqD5WpWGetGfl3OSmFL8w2z68tVulbPPAa2sfQi+6/HTbSrU0FsjwL8MHyF1lAwiunwXAj3nFgAWA9C6sPwPcy8yixnWPiFRnYrp8jUl1Le1Ezr72KRFYPC1YG6AiGB4php0einU5yfHrAKbEUixzdYNn4Z/57p/Rehdk4Ic0Np52IZ5CYRc9ktXZ/21cUqENN8y7gtlaBv7fhwMY2dY5isT6I7aNMGiRQhz2wmpU480OsV4djElEr67y8hNvgF6wxRmh7P1ZJrjBULz/CYc9wUqNwycRZ3aS+UBgq3oJybI5b73kb3YyQYxlLuz69hP3DXGV2ELOCZ7dStmj7i02Vt2JPT26j43NRaiBNhMDgxBKECDVPrF3w8j6xYG7QHp9ZCOxkI+gJQ0icIP87tNz36bmJT4accSvkXkDPROT9ljqjl5Rc3fxpxNCvKu7PTDz9j9wpzC8+P9COv5h5+AuOSDJDAuKdz41mEb tswtP8ry zD8l/rCUVXqb8vBykT/FhGTs+LLSPURzrrg9aqNEc+o5/qt2rJmxude30sCcsiigAI/EmZfFSErnIv9nDJFeCLAcNOLu9KbTgsfRLpwqXytF0npP6Yl7a6pZBMQZa1X6hJsinb5D8Z2iss/6hofCQP7SqS3pBA36IzyiJX3U+j40vXPmTYQZgTC8i71gVessyMec1F7nHXJT4kL2R/b3lHzAQO2utUDjWixRKrS53wDtRL+n538s209P6MXysezFOQq8GRkRIGHu7AdTVPUx0+zXI8g== 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 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]. >> >> Kefeng, can you try if the following RFC patch [1] can solve your >> problem? Thanks. >> (PS: I will revise the patch according to Matthew's suggestion) > > Sure, will try once I come back, but [1] won't solve the issue when set Cool. Thanks. > force/deny at runtime, eg, mount with always/within_size, but set deny > when runtime, we still fault in large chunks, but we can't allocate > large folio, the performance of write will be degradation. Yes, but as Hugh mentioned before, the options 'force' and 'deny' are rather testing artifacts from the old ages. So I suspect if the 'deny' option will be set in the real products, that means do we really need consider this case too much?