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 0163ECCFA13 for ; Thu, 26 Sep 2024 08:38:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 76DE26B00B1; Thu, 26 Sep 2024 04:38:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 71D076B00B4; Thu, 26 Sep 2024 04:38:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60B806B00B6; Thu, 26 Sep 2024 04:38:47 -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 4427F6B00B1 for ; Thu, 26 Sep 2024 04:38:47 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C8682AC060 for ; Thu, 26 Sep 2024 08:38:46 +0000 (UTC) X-FDA: 82606238652.11.A61BC83 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) by imf10.hostedemail.com (Postfix) with ESMTP id 198E9C0005 for ; Thu, 26 Sep 2024 08:38:43 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=hrHH6bZn; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf10.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727339908; a=rsa-sha256; cv=none; b=3ZpnoxzxQhJ03BVqJWxXIEYNmsPhfhq8BjEzTR2nhrHkAwiQy2o8AgHCO4Bs/gRKGUviUI f0TEfLIagLtcJKCF1H3HlsWgwnGdOS4YpG3BsUwy17QipSuZIlFU8slrgS9aRLTOY4rvvW gXpgnp+59K8rxn0x5ZJmludH2kwytzY= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=hrHH6bZn; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf10.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727339908; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TB5UJEtCsm4P4G++Jl8aN3PaUQKcMcrma/AP9vjcE68=; b=esTMVgQDqXtfNR11+P/OqJE6lGgouBLyRpUBe/MuhScRVCt/NNYGGqa56+Kg6Jaz25H1dD +D2RlrHVfr8m6r/a/s6423mXgSNm3wVXbk3NDJgUhv/8AvAsuxkv50R4hRMrwUHQVnKZKT 0tEXgjbVdan9yNaCpZXq4pgSe6rMNgI= Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4XDn7L52fXz9vQl; Thu, 26 Sep 2024 10:38:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1727339918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TB5UJEtCsm4P4G++Jl8aN3PaUQKcMcrma/AP9vjcE68=; b=hrHH6bZn0W+C/K+0vaSjpaGIrNJP6owsJIFnk3KdZ+Xa03lO/hX2HhaXTOF2uopzegA9G0 XAGcv4kbY0dAPJXEp6Xu9rzt7ub78J6U+Tx679BUugcVEFBTUWVjQOxwlWrLSxnTc+6+dX kOHLx+5+oXln8pR+sQLsnmofsGY18ruLylp+/pM7GJduP4u5Q9ugi43d6U2j05JscON3UH R0SKpSxbYh7245uZqZBB19elFTAnJu2cAQyBl25ttSJc2ZaW3O8wtQYVZCy128HnfVW61S e/Eix+qqE/0p5sCgWHdBIDvxHolE9MJjujmHc5k3/IP8h/EsCKsdDLUCsnXcpA== Date: Thu, 26 Sep 2024 10:38:34 +0200 From: "Pankaj Raghav (Samsung)" To: Kefeng Wang Cc: Matthew Wilcox , Andrew Morton , Hugh Dickins , Alexander Viro , Christian Brauner , Jan Kara , Anna Schumaker , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Baolin Wang Subject: Re: Re: [PATCH v2] tmpfs: fault in smaller chunks if large folio allocation not allowed Message-ID: References: <20240914140613.2334139-1-wangkefeng.wang@huawei.com> <20240920143654.1008756-1-wangkefeng.wang@huawei.com> <1d4f98aa-f57d-4801-8510-5c44e027c4e4@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d4f98aa-f57d-4801-8510-5c44e027c4e4@huawei.com> X-Rspam-User: X-Stat-Signature: auod9da3pgzhden7om7hs38qb3j1uujt X-Rspamd-Queue-Id: 198E9C0005 X-Rspamd-Server: rspam02 X-HE-Tag: 1727339923-466997 X-HE-Meta: U2FsdGVkX19SAGf6+1FeBwLqoC/+fuL995dpOJzUEIcirCStM1AgnPRqyuszh3EipjZxVNCDEWJFDNvyFRT33Ds5gIWteFLAaZwq9C8Ic5nzeQZWSuXgw4UsjPpQO+f4q91FoYnqb+09nZiBuAQabwCIHjsCpcHDIUScnAUVuIqOqFS9r+dBHyr0+gDvhxQjd59kXiYULS5lMBCATi5H1tH3FC07IrqHOP5Ocr0lesCOYBxSzqHCQaj3UIaXFAxGe+3mDXZoTm4bEQo6XibhGwlwV0sF3R66B53Jvs7zApCVtqHdThiaaBR2+0phKbhSvqpBy+MEAvlyrVXf4qBtuIMkC3xQnNQDhNFmVTEQVQe+04q+41NjRu5YP2rmq2ht3DE668xBf3yJGvzl6esz4xtUpbD7L2/+U8QfK4ghb4RlZfciUUjj2825MSG4LeT2cjE9UkMuYMa9ukvlntnAVk0xJxn3p289+sD0aI5YHKhU+fK9nFHET3pWmppOrHRYyTZvCM0Hp2lGYImo1baHGbz88YD8n7x98vCD9tTio7bLE0Vonc0bvtKIxBq5Ssg2kPjIeIjNkSCbMk5w7aB8p9TeNhLbVND3pgFn/5VZ2uFd+4flNREuGOtNqT/POVr8b9Fi/ng0eOzXlckFBU4EEAatdEUXoH1yzSlTYDLj2Zd+SplVUt03xA9jTYR/yhk7J93f2F/TlaNWVjHILcQ2CEwl+WnHFT63R1cA2vLRrlrCzacS9I01nhuBZPokaQgUKO6CCVYdM/TdLjR+/yMQmmyWJRV5fNsjS7jOexQgQn/jy1S6zSWD37TkrSpnp/uF7B3dm2azCwz0Nzt5wSMT3tY/PB7iIBeOxD5h/joAxBY/unKvL3UBBMjEPMsxdOA5pwibBrfdI/lppDtff0lS/w/P/YWSdkIOSfo0WBy+PwHJOCtE7fGkH+ncUS7rkMWtduxyptUy1ytbdhlgrIH 08wVAbi5 LjCb9mMSaai4MuyeTEgbRnYRk4vA8n+JpIp0ofg7T8TLO1hiQnJZILDFP2K8bdZP/07fblDwjAYZf359ZfGwx1LoW2IQOD3KTIXpEPdUZdBvIr0jZGE8BwXT/emW0hgG7aRB5kR0H8F3Efbv/MPUUAspuq+JEtFGrP5cgqqYrvYeTZd+PFMe1O+0qCN9muGMaA8o7QqPxmwjPoNr5LrqEezXS6UVNAsxFfB8IbSt0z2H2WbawLL4rqN+k1Q== 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 Mon, Sep 23, 2024 at 09:39:07AM +0800, Kefeng Wang wrote: > > > On 2024/9/22 8:35, Matthew Wilcox wrote: > > On Fri, Sep 20, 2024 at 10:36:54PM +0800, Kefeng Wang wrote: > > > The tmpfs supports large folio, but there is some configurable options > > > to enable/disable large folio allocation, and for huge=within_size, > > > large folio only allowabled if it fully within i_size, so there is > > > performance issue when perform write without large folio, the issue is > > > similar to commit 4e527d5841e2 ("iomap: fault in smaller chunks for > > > non-large folio mappings"). > > > > No. What's wrong with my earlier suggestion? > > > > The tempfs has mount options(never/always/within_size/madvise) for large > folio, also has sysfs file /sys/kernel/mm/transparent_hugepage/shmem_enabled > to deny/force large folio at runtime, as replied in v1, I think it > breaks the rules of mapping_set_folio_order_range(), > > "Do not tune it based on, eg, i_size." > --- for tmpfs, it does choose large folio or not based on the i_size > > "Context: This should not be called while the inode is active as it is > non-atomic." > --- during perform write, the inode is active > > 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.