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 65F90D6ED34 for ; Thu, 21 Nov 2024 13:56:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5D856B007B; Thu, 21 Nov 2024 08:56:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E0E1D6B0089; Thu, 21 Nov 2024 08:56:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD4DB6B008A; Thu, 21 Nov 2024 08:56:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AF2146B007B for ; Thu, 21 Nov 2024 08:56:52 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 509B180D85 for ; Thu, 21 Nov 2024 13:56:52 +0000 (UTC) X-FDA: 82810252560.29.B7323DD Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf14.hostedemail.com (Postfix) with ESMTP id AAD8610000B for ; Thu, 21 Nov 2024 13:55:51 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mVz82nDb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732197343; a=rsa-sha256; cv=none; b=jZ+PdlNz3kGMAopRTcDTwBb/wMwR+IEyP5ljYWWN1CZbipzHYkXfpkAaFxD9eWCFgtJ0SX ybB3FXQ29Jq5qzUtXQFH1enaUhmnIX6JW/e1zgjJPFSuGp1jyF3JQ+3PBsIzkEzW/+DaoX Na9aJVbx29lUJr5EAU2cBu7RZr2BG/w= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mVz82nDb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732197343; 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=H6VTsKEKFH+lx7r6h+YAEcJh+xm3cvslfQa17q41ek0=; b=i4fohTQwYhS7pmzVudGVO+ML7pJ2wwRKpSu6BIad/zIlmufLXLZayvtCC/Rz+kBEU7lNnI hjlvQWTzxiwRTLk75EdeH3Bte0+3wnp9ATfp1Cmn6TeD1wYhd8wNqDn/1of7y5HR8G+mxG qSTXnTddh652R4923n+jA/3Pp88k6D8= Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5d00e24d874so716908a12.3 for ; Thu, 21 Nov 2024 05:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732197409; x=1732802209; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=H6VTsKEKFH+lx7r6h+YAEcJh+xm3cvslfQa17q41ek0=; b=mVz82nDbFXdXI9swcnmHhkL+m/sxgTvY/ecBaqVx1gE27V6s05Zzk291WvLTPIg7SY Sxx2FJfbp2zKln/Lg82tz2OCLsNadzLKqkL/eZJjq6bMt0xwh9/f3/Mewbn2TAGFilZM JBCmelcm/yXv4O47waBXGgsHpxZmiM4UXsPCP7/1o2UTcv140aeppvbGOO2uZzYXgRVN SWvcadBVN8K7wnGYpEMV87afYy2Uq9YWpegTJurk0VF580RcV3vt36eto56+4I9wZBE1 R3T6NL0ysae/AUr95d+y8fFy9TIWKkxk+aocNI/gWaRVjdcD9Lc0L+LXZ9p5SGixfZzd fz6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732197409; x=1732802209; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H6VTsKEKFH+lx7r6h+YAEcJh+xm3cvslfQa17q41ek0=; b=gFQW0QMPuOLeLWn4wCcQNfW4h+o/z6UaEWziOzJKNLe3OjxL6KV0eOX4q3jjc9SsnS 5fGRGLpmY9WusuE1ipN8LwC5lhqJSbKTT/+Gqj0F3ackbGFf7RR4lgKCLBJFGlXaDUWc 8W2uD5+I3++QjdJiNdoiJYa5kLzn3x++m6Uj2w0o2a94ZV4eFe3RGLvv2sUFfRscakUi or/NzOrG8kRJnJ/wU+X//KSdNu3Qhi6fckI3Vo/PtudB2fFOv8Q9J2DH+cF1wGbT96m/ HTf7p3Vg4VJLHr6ZZixsCS9yu4lQDDPjT/GNQHrP0HCIffekSrQFYy2umVrTwM9FIWAW gbBA== X-Forwarded-Encrypted: i=1; AJvYcCWwh7XKa0UTUJicWNaqX3WvWjUT/iKspfID4SJWFIWFeRdfEq9Hb1koTfBlCohc0ZIoH14hFKIhNg==@kvack.org X-Gm-Message-State: AOJu0Ywcqe5UrbOjBnmSMj3iKrimoghl08lomwEi4MHBnFqwp3YjEN0m /sDESSYV3mLPQSZzLtqNaSfQueF05uwV5xuEN4aS2HUJ1TIXG5afturmuDb/2JMM2YuCejh05Sr N1liriQweJHwxeMe9Bd6If5B2IuU= X-Gm-Gg: ASbGnculdonHf6/MeRIm42TxCcLTEli2WD8y1GEGUo+3Yr/iqMOQ3rKnj9EjFnfmMPf 0O1t+/wU4R7WmwJMsLzmJVyvlR7zdxw== X-Google-Smtp-Source: AGHT+IHbmuJ7KgininVEU/ALyo+nC03rV8ASRUHLBsEK8cAvNbVaYmbKGLO9xiUHXWLwlDvA3LbY4pqkbb8Fahimsy8= X-Received: by 2002:a05:6402:5108:b0:5cf:d078:c9dc with SMTP id 4fb4d7f45d1cf-5cff4ccfa11mr4811055a12.22.1732197408592; Thu, 21 Nov 2024 05:56:48 -0800 (PST) MIME-Version: 1.0 References: <20241120112037.822078-1-mjguzik@gmail.com> <20241120112037.822078-2-mjguzik@gmail.com> <20241121-seilschaft-zeitig-7c8c3431bd00@brauner> In-Reply-To: <20241121-seilschaft-zeitig-7c8c3431bd00@brauner> From: Mateusz Guzik Date: Thu, 21 Nov 2024 14:56:36 +0100 Message-ID: Subject: Re: [PATCH v3 1/3] vfs: support caching symlink lengths in inodes To: Christian Brauner Cc: viro@zeniv.linux.org.uk, jack@suse.cz, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, hughd@google.com, linux-ext4@vger.kernel.org, tytso@mit.edu, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: AAD8610000B X-Rspamd-Server: rspam01 X-Stat-Signature: 7s3fw9qd7jixq5191r5479eozj56bcmx X-HE-Tag: 1732197351-779767 X-HE-Meta: U2FsdGVkX18dsaA+u7Lp+HcZTh1bMvo76nzOZZmvyWD7XmnkVwd+zTEnIn63Hgts9jnLchSvDkKcFQBYz9DVFxE5WnQmnOFd/T73LDc5WwTHiwJdxb/+tn1iy6LACL1OB5JOE+5ff1oliQ/9OLbReNv2CHaLdYTm8ASzsmwGJwaD3zHDerzSXnhs3GKofTaYddYg2I5I9qiZN3VUKvQx1vM6xdWJUKHTCamzDFYP2ysv+z9ghor8KMyRzvujqH4/TSkVWz7UakgJMB7KETAI0MvunhYJ88IiMMllKKSbNX7zPSoigcMYIT27Vo4UM/EKx6RQSYxcygOC5iWvPwKZcLE2OpBjVF83/Di6Xt35zUdCC+IKurW+3oUg/RsI2/+qsar78O9Dt5iRLLeQm8oA2Ick5CAUC68zgs0DRf/Zr+btRlow9u0y7cAIF4NXONqB94h/4/NQ9OgwQvxrwxiIxl1QUhxpg560Ki0WVN0NCHit/zB1j3W6xBrr45AOFN5ksCYrsxNt5Izbf97FLaXOvUHAmC/XZy9Kn599lxDp4SGWEBnBKimpC9t+p7qrFiZ+GTk0ugNkaILQqt9/Vr9d5oNFgRA0/YeMmTu4T5ZELzoFASaHcthF9bp0CmqJAnmo2KpekEf06Z77izFyDcpaKrMmtMrhb4m4xdHg06d7mpXJpyAnIanFZo0JsRkGfj6FyDZDupDVJNp3wtJQVbX338U3oR7rBU8R8DK/inxKUVkhBDxiJG7Ya9gN7mIKqVzUZJ94YqWsA8rbANWWuWin1wzlelNtwWXnCV6ED298CGSV/RT2Iwk06cfyZVBRbfnbnz2FCPzSfl2VUuVmlhUIJJHimHteZAOWJEle8vNtYNHEslyfyJQ/ix7eaBl6oX5uW/AOtP+Zl6rxAcBawMNjVgBTb5jRH84zk/gF5tM16nNUcBdljOrFlI+n23HvjhudRQwXWB4OnmUK/MEF+Lf F5zDr6VN 7LNacpOlQUQRgbv5p5oaIpOkz1gwCmugIaZFAICwpEqb8Ccay8S2TZ8C4Tn0hWhJHtly5sHgmDjaBYPNHL6mDs+G+ZnaOuBgclBe3hU/lo7KHapiP1LnOvtLMm/Wm8s5pnZ1svveLkQJEu7vSGPpSHGdBdyocNMThovCkbETpYkOf04F7o2mbwOmjqwvffnZCG2k1bS+bVWUvrWEKl02JsMgsVVhkt0ZtkLZuhoCrKs0O2LnsPKnIT0RjuooaYZKf/DJvXcTa6JN9n4b0zjHMIEP4EpNOZ5sT8BSbXGpWiC92+3QT6UP+RNYfeKj2/bxIHVrk+huSyXIOHi9QWfwWPDtLKH8pW93Hq7oZTdnOvdZe56o= X-Bogosity: Ham, tests=bogofilter, spamicity=0.003344, 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 Thu, Nov 21, 2024 at 11:12=E2=80=AFAM Christian Brauner wrote: > I think that i_devices should be moved into the union as it's really > only used with i_cdev but it's not that easily done because list_head > needs to be initialized. I roughly envisioned something like: > > union { > struct { > struct cdev *i_cdev; > struct list_head i_devices; > }; > struct { > char *i_link; > unsigned int i_link_len; > }; > struct pipe_inode_info *i_pipe; > unsigned i_dir_seq; > }; > > But it's not important enough imho. I thought about doing that, but decided not to. I mentioned some time ago that the layout of struct inode is false-sharing friendly and the kernel is not in shape where this can be sensibly fixed yet and it may or may not affect what to do with the above. On the stock kernel the issues are: - a spurious lockref acquire/release -- I posted a patch for it, Al did not like it and wrote his own, does not look like it landed though - apparmor -- everything serializes on label ref management (this *is* used by ubuntu for example, but also the lkp machinery). Other people posted patchsets to get rid of the problem, but they ran into their own snags. I have a wip with of my own. Anyhow, with these eliminated it will be possible to evaluate what happens with inode rearrengements. Until then I think any messing with the layout is best avoided. thanks for taking the patchset --=20 Mateusz Guzik