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 EB37EC27C6E for ; Mon, 17 Jun 2024 06:51:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6AC956B0141; Mon, 17 Jun 2024 02:51:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 65CF36B0142; Mon, 17 Jun 2024 02:51:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 524E66B0143; Mon, 17 Jun 2024 02:51:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 33D666B0141 for ; Mon, 17 Jun 2024 02:51:11 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9C665413E8 for ; Mon, 17 Jun 2024 06:51:10 +0000 (UTC) X-FDA: 82239458700.12.52719E6 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf02.hostedemail.com (Postfix) with ESMTP id CAC708000F for ; Mon, 17 Jun 2024 06:51:08 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718607066; 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; bh=U2b6875TBtU1VZie+U6hOjypwITZdKNmEU7mDla8ZZI=; b=DoaHy2K0b7BazPG2MvNFJ0PQjGyS9CzE5rIOf50868vbJtRSFODm4qLNLzuZNQD8NorKVs rzct4a1Tj9v2iEQwo99cQJjPhQ0NF0oc9/AirEYAQIjOGVYRuyIVUOUZGn4bO3HZwSE1eR fXFY4MNqYVazpUMDHaU2PyZrvuzYdQY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718607066; a=rsa-sha256; cv=none; b=VjFUTPwH8jtZk8+3MoDKImGeYyXMizy4ZXGb4m96DyhTw+zAICMQ5KJ7+OMj98bmdEUkcZ a1zuBOHEh4+tZqMJ4/8zSl1cREDi6+fbCYF2Zij8Ta0oARHOmkS8E8aYlyOoPDwI6Fugzz VsYhrYett53SCjMU++X0HCaZqLtoJz0= Received: by verein.lst.de (Postfix, from userid 2407) id 91B8668B05; Mon, 17 Jun 2024 08:51:04 +0200 (CEST) Date: Mon, 17 Jun 2024 08:51:04 +0200 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , "Pankaj Raghav (Samsung)" , djwong@kernel.org, chandan.babu@oracle.com, brauner@kernel.org, akpm@linux-foundation.org, willy@infradead.org, mcgrof@kernel.org, linux-mm@kvack.org, hare@suse.de, linux-kernel@vger.kernel.org, yang@os.amperecomputing.com, Zi Yan , linux-xfs@vger.kernel.org, p.raghav@samsung.com, linux-fsdevel@vger.kernel.org, gost.dev@samsung.com, cl@os.amperecomputing.com, john.g.garry@oracle.com Subject: Re: [PATCH v7 11/11] xfs: enable block size larger than page size support Message-ID: <20240617065104.GA18547@lst.de> References: <20240607145902.1137853-1-kernel@pankajraghav.com> <20240607145902.1137853-12-kernel@pankajraghav.com> <20240613084725.GC23371@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: CAC708000F X-Stat-Signature: 6y5j8tqwejnqbabaapuqxe6gazk5zs64 X-HE-Tag: 1718607068-452222 X-HE-Meta: U2FsdGVkX1/s9+tN5VAbCcZMLeFV7fYoUalD4uMnqNA+Jhg+8llNau3LWQrTRI52TpylALCsGUW+p69MHOpO97/6OxCLFxSjIBKLTBZuYOLPJtx5G2XBQe6XXjqRwO35FdNahZi7mcnhG2UuC5ieVHdf4nTJ8dNZvVIBwjZs1k69S125vSqI+IREVjbvjY+v28QWV/3yXJwmVMaXNfsFUq6rfc28vf8zNu8bKtKs/794g/wlg0QGqebzfxG6xaiBJKi6My21gxcmEyUK6qhO9ffJXoMr1Luh/ZnXUmlIs3MlD8Oc86b08VkFuSU4Lp8ZtIpzIV1KD+ZicFFCnOdObWQnbi+9tT98bH9LYpdceVDWwHhgHyLtZ7SiRjcAAnN0NPXCdB5wUthhQN2Wik3gvlgzhb4mUrU2CnDq8mnqnvhOjN0SDr1KKmTwGJwUXyg8wIMbBFs1cSgKnViVKlZ8s565pVw5TK1IfwJVId+S6dQfdrqnzW/62+pywvVVvCpV/9UIYeuhgooxUxEIRlBjuRulPcbFG5JyUG626Ufz25s6pZdzCniZY4K6P+/K0rU/fg9+LOZLe8/CphyLNplKOLIqw6RWE/iZlwuengvSVPA/X2/y/UbcEX7sfRpIfjwbQqy/IrvZhx9dEusDWhytsSQhBzd1WWhBSG0L+yKULk8M8HQWURJN5niiV8D1k0J3KyXHOPmkGpGmEFNRCad20R3Ywj4jYzCHCnVbd9wM7FC/7CorjUKdDsvPWi0xnyCOrLEaza6q1lm2ckzVILv5B73HX4Dy/+VcP4+ipFwhK2HyYvSgM6n+bAmIpFwkp2FJJI75s7hr0Znp2TUAWyhkKfAL5cCiueS3vq7DXCgEldE1X6b2UfzS2EbbRcJMVhNg5lbRetwNGzVIucqgzcua7N+gtweVse11J0Abj+v74KYWigf8J1T3c8Dihg7HXSmpNFdTES+QPfhkfqoWxLe enqQEZxd Edj0wbQEw+LxgUtkkRcs3Xyccoq+xerx0HYjJS5n+WebTvtgN0iZhSQ3U8B+479yTa1AsGgrA3iE2ip4= 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, Jun 17, 2024 at 11:29:42AM +1000, Dave Chinner wrote: > > > + if (mp->m_sb.sb_blocksize > PAGE_SIZE) > > > + igeo->min_folio_order = mp->m_sb.sb_blocklog - PAGE_SHIFT; > > > + else > > > + igeo->min_folio_order = 0; > > > } > > > > The minimum folio order isn't really part of the inode (allocation) > > geometry, is it? > > I suggested it last time around instead of calculating the same > constant on every inode allocation. We're already storing in-memory > strunct xfs_inode allocation init values in this structure. e.g. in > xfs_inode_alloc() we see things like this: While new_diflags2 isn't exactly inode geometry, it at least is part of the inode allocation. Folio min order for file data has nothing to do with this at all. > The only other place we might store it is the struct xfs_mount, but > given all the inode allocation constants are already in the embedded > mp->m_ino_geo structure, it just seems like a much better idea to > put it will all the other inode allocation constants than dump it > randomly into the struct xfs_mount.... Well, it is very closely elated to say the m_blockmask field in struct xfs_mount. The again modern CPUs tend to get a you simple subtraction for free in most pipelines doing other things, so I'm not really sure it's worth caching for use in inode allocation to start with, but I don't care strongly about that.