Received: by 2002:a05:7412:518d:b0:e2:908c:2ebd with SMTP id fn13csp347783rdb; Thu, 5 Oct 2023 07:42:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHO74LZFgnqdv6eWsCkaS9lmf3zBpZ6aK8s5CRdf03h2oX3af3LBEXj8MVnbvTgVUDOzfmq X-Received: by 2002:a05:6a21:3296:b0:165:408b:912d with SMTP id yt22-20020a056a21329600b00165408b912dmr6360950pzb.59.1696516969874; Thu, 05 Oct 2023 07:42:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696516969; cv=none; d=google.com; s=arc-20160816; b=KIG42uEwyRd9Ig1VOh/tIg+JBvJ6bmpd95oesc+hLe1sxFVeR/D2fXysDfAEGFk0Hy WmJZLbC5z7rQnPC7GA1qGEo3TN/k4aGRNOJTweC14QzONz5hzwZtFEY117PBIMCW1fkX OT0pn6NnpusKnq6y5TEmJ7jpqotFbflyNeHBDWYllhJCPmLxykZwviE1QqwgXhP754LL 0MmygthxXOwuxqeLLlpsBkEMr50+awNNZSxaPtwvEQglIzMjRMcXMN+m8dr1zetkxk0t EMbzm0hdSvQDh4K9IiT63cIZHV2mOG6abLqOw9NbAF0TYjIlNR8QPf/lfFGjWz8xDA9y cefw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=4jC87LRLfPQjR1VISHvg0qT/jWQlCxYBj2wNUg2BXEE=; fh=gWFhcgHJGhkoaoeTBnFdWaZhIUEOyrcYTWj5bm5rz3o=; b=A5yQKJNSFDSkWOKENncYI3WGrusEfeFoq49H5ErRUQlo2xmzhgQ23ZdGUcrdxRSZrV ESfbVujffNdawNrDhK4OGff+ZceLWd7GGTmu1jRZHokf1yOQ8MRCGdGUOPL0mJ6lrM6i izx9qeIVFCrPS+MV+pnYO/yMVDJEOxAtMmZ9Z4Tj2+5e2178k2hKyeIy5ctd4SB0QJ3u eHUElA3gPmgIOtqkFWCTwcBxCvSVTXmcLvjVzqPJzJxBrgChglOjtHkTa4OvE0xcIy2F 4Nn7OcW/ie0w1rYOmjJX8GpmJ0LV4/5zb8A61TVlohF76kj5ND9dDsZxq+F1vi71r2lP /SPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HLWo6k8p; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id j72-20020a638b4b000000b0057754fd03a3si1633325pge.144.2023.10.05.07.42.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Oct 2023 07:42:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HLWo6k8p; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id C0F958600C60; Thu, 5 Oct 2023 07:42:47 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239351AbjJEOmP (ORCPT + 99 others); Thu, 5 Oct 2023 10:42:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234122AbjJEOhv (ORCPT ); Thu, 5 Oct 2023 10:37:51 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 729BD8A4D; Thu, 5 Oct 2023 07:03:25 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E4F5C3279D; Thu, 5 Oct 2023 12:45:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696509955; bh=OyPYLq8qw3jPUQ7rA5KJM4mXFbg5lNRBN/Aw7zBp+L4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=HLWo6k8p032N2hH+EknnrwhrZQgP2503xfFAY8bwfX4utLsM8uym7mbVNhp2BYVKB s+jC7tV0VdyNFMcXr4XY5CLzZRiRfhxp64CqGdzalVzcsOoSnWyge2bcwtZbuKVsXb cAIURc3dJ/i0srVdjL4Idvbs6WxQC9OWICK9BB4KliJ+5nMgdgpgeBu4MnuTV5WeXI Vjk46daoz5mBOebcG99aKmHcDqIUaYKGXsp0lPX1Y3jUxzhzQtjCl8bO1IR8fCyBNi sF3RgZTCDtAYO7kM+ZvbtQOT4K9gLYjWwE2RSIlX+8EaNlCspTKPe9DXyjUChbfEaA yNqffQfYE4z1w== Message-ID: <9af5c896da0c39c66d0555879c04c23fd853c9de.camel@kernel.org> Subject: Re: [PATCH v2 89/89] fs: move i_generation into new hole created after timestamp conversion From: Jeff Layton To: Amir Goldstein Cc: Christian Brauner , Al Viro , Jan Kara , linux-kernel , linux-fsdevel Date: Thu, 05 Oct 2023 08:45:53 -0400 In-Reply-To: References: <20231004185530.82088-1-jlayton@kernel.org> <20231004185530.82088-3-jlayton@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 05 Oct 2023 07:42:49 -0700 (PDT) On Thu, 2023-10-05 at 08:08 +0300, Amir Goldstein wrote: > On Wed, Oct 4, 2023 at 9:56=E2=80=AFPM Jeff Layton w= rote: > >=20 > > The recent change to use discrete integers instead of struct timespec64 > > shaved 8 bytes off of struct inode, but it also moves the i_lock > > into the previous cacheline, away from the fields that it protects. > >=20 > > Move i_generation above the i_lock, which moves the new 4 byte hole to > > just after the i_fsnotify_mask in my setup. >=20 > Might be good to mention that this hole has a purpose... >=20 > >=20 > > Suggested-by: Amir Goldstein > > Signed-off-by: Jeff Layton > > --- > > include/linux/fs.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > index 485b5e21c8e5..686c9f33e725 100644 > > --- a/include/linux/fs.h > > +++ b/include/linux/fs.h > > @@ -677,6 +677,7 @@ struct inode { > > u32 i_atime_nsec; > > u32 i_mtime_nsec; > > u32 i_ctime_nsec; > > + u32 i_generation; > > spinlock_t i_lock; /* i_blocks, i_bytes, maybe i_s= ize */ > > unsigned short i_bytes; > > u8 i_blkbits; > > @@ -733,7 +734,6 @@ struct inode { > > unsigned i_dir_seq; > > }; > >=20 > > - __u32 i_generation; > >=20 > > #ifdef CONFIG_FSNOTIFY > > __u32 i_fsnotify_mask; /* all events this ino= de cares about */ >=20 > If you post another version, please leave a comment here >=20 > + /* 32bit hole reserved for expanding i_fsnotify_mask to 64bit *= / >=20 Sure. I suppose we could create a union there too if you really want to reserve it: union { __u32 i_fsnotify_mask; __u64 __i_fsnotify_mask_ext; }; --=20 Jeff Layton