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 2B4CDC2BA15 for ; Mon, 17 Jun 2024 23:18:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE4DF6B02A6; Mon, 17 Jun 2024 19:18:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC2466B02A7; Mon, 17 Jun 2024 19:18:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A825C6B02A8; Mon, 17 Jun 2024 19:18:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 83CB16B02A6 for ; Mon, 17 Jun 2024 19:18:15 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 31A1FA18E7 for ; Mon, 17 Jun 2024 23:18:15 +0000 (UTC) X-FDA: 82241946150.20.29E60D7 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf22.hostedemail.com (Postfix) with ESMTP id 47C58C000B for ; Mon, 17 Jun 2024 23:18:13 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=GlH7XuMx; spf=pass (imf22.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718666290; 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=gaehIoCCMbdtbvnUIS3Bk9WXrmvq/8zVNdJb/nDEkms=; b=qgCqYE7E4K7zshVKHcRlrtcuLZ+dlL4FAl2nyMkcoiKVJb2SI0gKTfq/Lc++oM0jhCUJ/c pYGxebks1FlB1+VApc6ABki5Q76BKqLEYdkLvRNBL69/kXAUFnaL/kC1BoxoTxgSNhiPqI rqtCUwF4otttmYNbX+QlK5PFfQ+re6Y= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=GlH7XuMx; spf=pass (imf22.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718666290; a=rsa-sha256; cv=none; b=5Hsftc/ZBhCuWvnQ4Nm5X9LjdlZg/KZro0spEYm7veaLHQ596Fs561qK/j0aowqy+ebD8B IH7P/zZJj78IFQDXczVUKSaRDgydqsv/pUbbUaGakhi20d+6L96hZ+DE96u3VnhgX9WTXc lpmS+XN1L8kaFpL/Euy0A0Mqf8Ywfrw= Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-70436048c25so3733091b3a.0 for ; Mon, 17 Jun 2024 16:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1718666292; x=1719271092; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=gaehIoCCMbdtbvnUIS3Bk9WXrmvq/8zVNdJb/nDEkms=; b=GlH7XuMxXBAIAnU2OZIaHuyH6Z6NV+wgXdMtTx0jgGyrnVJhvh0HDM0cN8DzY+h8Ut UeiRTISSp+5wm4/K88JqNM8FDMQ62wIh/ROWBhJXC1Xzmr+XOJqpPsYqScvf/5RJYcOv iQxCvV7ijY+/F2W+HASQ8ZBauecv+c+WC9mw/R4QwtL7lf2u7vHsNq0RBhCpx1qIwDgQ zmpxc/B7eyvI8QkSQ5m0FlBVoqkJQfDJRSmsamIcUMVXb7gbainbkfBH6pMh2uog7Tnr lsPcGuK1h0y24D5Akwe/RsF+Myxz2VN8V7CJQ8E2vWYYZ4Y+v//g5AKqprHe+GarpJA6 OtFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718666292; x=1719271092; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gaehIoCCMbdtbvnUIS3Bk9WXrmvq/8zVNdJb/nDEkms=; b=kOwUetjIqCftm0w9jOUwNPZ5IzHhci4pJk6Mu5QVUUesaNCUcPQS3nLuK5u1wNo7PX Z1D8QrdNgIepeTiay1DtB5rI1aiyQQVZ1wAGSRqQJKDQpu2V6m73tgi6ZWqzKt+Kk2/G Skw3U9OQiAjQIjhcACtOmak2d+4M4xdEMPdJ+Joi1/Jl2ZM17ZUpootdy+OOy7Frm5/V rS19I7sfsWTpQvLhJVIbrywj6EzmTfCD0xk5AqDJ3KFUuol36ZIBMZMb+yz4ZlknjNju 0jW9G1K12L0t4iJrlfCUXVofRRnf/suxiG9wNkL1F2Vp6zSi5+meJhWK4YM6h2LjJrdi 1zDA== X-Forwarded-Encrypted: i=1; AJvYcCX9+hmCpwtej+zr4gWXmtXHwGc1nbwM43RZWGXRpovPBQLRwGL/KIYmZ2QCxWsOaBPdoZSoJ/RF8CkNYNbTbbZCmqs= X-Gm-Message-State: AOJu0Yx8VL6G99We0kY9UuMV9H1tsX8iNKS3iAYV4sPXfM8wWkm2d2ua kEv+3E+ba7S46qWM3kp6VLHNVRiOiZtr7yYpwq4RDbHok/ElzX7CGSSv+ZIuzEI= X-Google-Smtp-Source: AGHT+IFZ5VaDbnJgrc4upZ8ziIxaNBi9yUsEpjQiocgmkB3SKh6FhcEhl90ontDwiZTKwkEGHbQzuw== X-Received: by 2002:a05:6a20:321b:b0:1b8:5967:45bc with SMTP id adf61e73a8af0-1bae83a39fdmr9164501637.61.1718666291634; Mon, 17 Jun 2024 16:18:11 -0700 (PDT) Received: from dread.disaster.area (pa49-179-32-121.pa.nsw.optusnet.com.au. [49.179.32.121]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-6fee2d3673dsm7103023a12.69.2024.06.17.16.18.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jun 2024 16:18:11 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1sJLc0-0025gT-1w; Tue, 18 Jun 2024 09:18:08 +1000 Date: Tue, 18 Jun 2024 09:18:08 +1000 From: Dave Chinner To: Christoph Hellwig Cc: "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: References: <20240607145902.1137853-1-kernel@pankajraghav.com> <20240607145902.1137853-12-kernel@pankajraghav.com> <20240613084725.GC23371@lst.de> <20240617065104.GA18547@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240617065104.GA18547@lst.de> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 47C58C000B X-Stat-Signature: t1hh3x3u75ab8diqxdetjw6fq6su73ca X-HE-Tag: 1718666293-88872 X-HE-Meta: U2FsdGVkX19qRKwS2hx3/SFzDNyoC9ivBDItV06q0I0wEqfPUUFcZbDnJ1AfBINZOXbIR9+vjwQX+heoYzswU3dVDofIR5k0BTx06vLRqSk4ObX0ukfZIvpKQ59B9sing4jh63sIlCqdkSrz2euHGUc8k6kyKAIVg1K3WVulMJLhmOUghUW3uQ+OM22G0whdsI5SmDvQgZsUoqwawYlW+nwdbXK9P1SeO7AYn+3Rkwx8JhXPk3+tdQzm/NXTfYKybn8ECglH2euhJeSESun4s59Qj1vbOBVZzo44HBwTJ6r5e8s7hpNuUgz6fp2SuDaLwWtj4khsNedvtnw+eicwSLrqBkw47t3vwILlqIb1laf0D8hQmq5CcdQKV0vj2gqInJWrFGqpbDdHK/32PumgzffC9ee6IOBIvvA/AZIEPSqE7O/9TclpuwaA0WZk2z/6AEmgEJyGezFZRcJf4mCuqMPBn+r31isMGnpXPnL3C6Kv5dHFnuPJHa1JBz6Fi6kOyksLUDbE+VtesYR4j/jNO8CBdW3RQa3a+haEefRQpkyMYLX93tLfCSDLpjAo3J0JQHcj+U5yNHMnbhhntQCjZItTzVrJDStEGctP9/G6L9b5sLeQdw1NKyd70Nv0P9LIn469w9GdH/cE7hDBCQEuWrnhMA3OtYaaCRuNTXisX9JNKZ1jb7HDDfm565O4bi/rlT6jcyhKkMxvr4T6KtKJMEenWbcaPRxvPPLpw97fa/uk36FWadB8e2tQ9HRkFWgvfdJantr6Aeyxn/fJqi2enjPnpnIJz9shNdrVjXXb73ukPer9rwopCLG37xb2ftlnfgytJJNFMkxgh9sR0wu4UBqfAMMYNaeq6hD2eUxBvFwppH7U1k7GTraToYhvNdfUtc58qQ40WbZM4PXdh53l3Se+XVqsm972BlInH04592oy6x+khey4S/A/rkfW8/oq9mptK0/SuDcpiGq6PNK TRbQeK8W Pvg8lRYFhKYp0ZdG0NS/EXxk7FJ3DymZQVugoEztbxm8k4rwKpGxkyWqwRTvMMA+3oaQ/rzL3ghNGwY7VY+0QcDyE0XMyLT43+L/cG+kGWlkSKyhPGhO1cMjYiEKcmeiVrAhUrFlCdJvKqKiXkL+nR83Pv9x+qOlLh6s2nv+oQDbtC47Ux+AMtCBSh61OOgv2mE+nvOIz8/zN39Va6FqlKm/x9CnA8PIiSab/q0Dhtj+NpZ4vtXzlS/Mr5qQAmqfpb9vpQpfCaLZrH8DM3kKHbgTeIOKnVZUk1qp5sgflRcg+LVLSWTA5dxyLdB7LC6MmfgzTBUnBEnyUMdCoZ9+x4lEfd1wTzapoy9DBQz5LnI/4g/SkTr8r59l91wYfva69X8B1pv1iSn/I2Ek= 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 08:51:04AM +0200, Christoph Hellwig wrote: > 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. Yet ip->i_diflags2 is *not* initialised in xfs_init_new_inode() when we physically allocate and initialise a new inode. It is set for all inodes when they are allocated in memory, regardless of their use. Whether that is the right thing to do or not is a separate issue - xfs_inode_from_disk() will overwrite it in every inode read case that isn't a create. Indeed, We could do the folio order initialisation in xfs_setup_inode() where we set up the mapping gfp mask, but that doesn't change the fact we set it up for every inode that is instantiated in memory or that we want it pre-calculated... > > 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. Not really. The block mask is a property of the and used primarily for manipulating lengths in units of FSB to/from byte counts and vice versa. It is used all over the place, and the only guaranteed common structure that all those callers have access to is the xfs_mount. OTOH, the folio order is only used for regular files to tell the page cache how to behave. The scope of the folio order setup is the same as mapping_set_gfp_mask() - is it only used in one place and used for inode configuration. I may have called the structure "inode geometry" because that described what it contained when I first implemented it, but that doesn't mean that is all that is can contain. It contains static, precalculated inode configuration values, and that what we are adding here... > 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. It's not the cost of a subtraction that is the problem - precalculation is about avoiding a potential branch misprediction in a hot path that would stall the CPU. If there were no branches, it wouldn't be an issue, but this value cannot be calculated without at least one branch in the logic. -Dave. -- Dave Chinner david@fromorbit.com