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 5CC25D63920 for ; Wed, 20 Nov 2024 10:42:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E82276B008C; Wed, 20 Nov 2024 05:42:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E30FB6B0092; Wed, 20 Nov 2024 05:42:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF8726B0093; Wed, 20 Nov 2024 05:42:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AF37A6B008C for ; Wed, 20 Nov 2024 05:42:51 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 33F94A0A37 for ; Wed, 20 Nov 2024 10:42:51 +0000 (UTC) X-FDA: 82806133662.21.229F71B Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf04.hostedemail.com (Postfix) with ESMTP id 5B46E40012 for ; Wed, 20 Nov 2024 10:41:44 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TeMPFUkH; spf=pass (imf04.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732099219; 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=g1Fye+w9f2/wqLsR/K13urMmL0eynzt5Fyy+QvQyjT8=; b=Ng8EJ604hlapRh4Xwl7Jwb29BQIKD3s5pYhje/no+F+GHrZjHYxbzUz9hv7pT/3LzBbnAI YA4JepoytJJxcXHH8blXi/jrtK2ogOMmHa9Tg62CtSen1Pa6BS7d/TzuqT24LiMFIS2hBn neyAnRA3Cp2Wdcb4/R/ssmdKiQ6BISM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732099219; a=rsa-sha256; cv=none; b=wJcySwG+IskbQ1eCJO8RWgnEWALmoTnuAkwvvBOxbg4SZ3llq6yovGb2aIWO4x2xia35QB 31QpjSk3yje7ypdJGaN3179o7WTYyOeLcK9u+dkUFAq2MiEkYUMHTzuLyLLok7U261rgrT bUeVVaAFN1j4+mXeP+hkzm1kPRdHuhw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TeMPFUkH; spf=pass (imf04.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-aa1f73966a5so834375166b.2 for ; Wed, 20 Nov 2024 02:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732099368; x=1732704168; 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=g1Fye+w9f2/wqLsR/K13urMmL0eynzt5Fyy+QvQyjT8=; b=TeMPFUkHIu02njDc/lTrTSBzPCOgbYtoB1AgugCuoa24/t6u3VUW9+IOUa02trdZXL aOPocCx5AMq3SkZEU1Hsti97foS/su7X97+wg75tFkk6C7HqPtc8KT2EJ0Yu+EjId0il oLFzYJCWg1UEE+2nAPA9OaAMEGufr5hcJMmhygWADJ3S+PyyYR9iKuuLmJ3jvb4D4iD8 +Oq1Z3e8T1nc6XgUKULUk20txzXA3jR9in1Wjt4wdhw7qEp6orRShOdD0Nwt41Jx7eM/ LZrqYnHVsx/TsKGcjnCadhOcJ6DIz5g8K72R8GoSNzwXvQXzFe2KCQrNPgZ1c8x+v9Yk KxlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732099368; x=1732704168; 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=g1Fye+w9f2/wqLsR/K13urMmL0eynzt5Fyy+QvQyjT8=; b=qRPPd2ldIvZ0HwFHDS9E1c0BltFNp0kBr/WyAmbNqUQ/QgvzfAfHBNGxx7I+P8vKdW AnqFWmtpydOqP+XsRI+iv+QpJfpODM4DzClYZuMTX3eVVO/Tuq7R2komIHH446YOPKnb qquqvPsS53YUN0FFow0glBBEGJ2kcTAMI4f/kM9ui3GlVvVro2H7x4uNfmfxZymVb4rt aSD1tQOvitcFqTDnKW3CilbBgnfhnP8yX/iKy2qoXQ2ITEj/PrTiTKMzfwhwPhtqEsds WRtlQemrTnOAWAba+EoWXnDOwvOZTUidbI6fDktzO4i4cLSJWy3PWMoUFH1/K0VYdzdS ctjw== X-Forwarded-Encrypted: i=1; AJvYcCXr2AeUK7CQZQFnzk2nizCsxM/QMjzsuSbHUjC/GAh4gKBV8Tn5UHC6uDC9eDJxNiAH+7fJJRqGgQ==@kvack.org X-Gm-Message-State: AOJu0YyQP1yw5XaUj+gQrquvU4lKv/RsHbsrCTOg+2Uh4XmxY3j0iiqO F/zFHesC7S5ezDcug81A8bZl4pLsl4r/53J6tH9shHk8lCpOZb/MMgvKKK8RqY7WX22oXiCXuoP blM/IntEROjErvq5dyEMc/oR0naA= X-Google-Smtp-Source: AGHT+IHvQxdoP+pAvWn1yN9/vfpnNgFvtu0z7BICfkNMmGGOWDcXwtOpUgaA6XYGwsQAvynctV9szk8UEj3jV6Hqhts= X-Received: by 2002:a17:906:6a04:b0:a9e:d539:86c4 with SMTP id a640c23a62f3a-aa4dd5481d0mr159817966b.9.1732099367707; Wed, 20 Nov 2024 02:42:47 -0800 (PST) MIME-Version: 1.0 References: <20241119094555.660666-1-mjguzik@gmail.com> <20241120-werden-reptil-85a16457b708@brauner> In-Reply-To: <20241120-werden-reptil-85a16457b708@brauner> From: Mateusz Guzik Date: Wed, 20 Nov 2024 11:42:33 +0100 Message-ID: Subject: Re: [PATCH v2 0/3] symlink length caching 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-Server: rspam12 X-Rspamd-Queue-Id: 5B46E40012 X-Stat-Signature: g77goo1e93shjn5acuhiq3hxdgppb9ct X-HE-Tag: 1732099304-246767 X-HE-Meta: U2FsdGVkX18iJx/zSFQ9KzfOQsIdoW9BBRxW6/RqIuV5hyy0KaxY9ljJ1gpl6EuVnHP/JrEHPPO8fwioiD89pOhxHJOzhyYf8b9vQYvRV173C89Q0F9emOx/QBNQtBWqt0bM4PYd7hLhpZqFUj+hKg/D7x6n9NphxH0XNlbXTEU7NX+fem1VkSDl3w0/aorOEp6xtGP1SYpg/3xsfAcC1raxw+wApzcnTb7vBbxZ13LETm//qtqqsdXAo+ieaKpUGltSGbJB1nDk/aluRGSn1wbFa9tv94DhxYw1oNHm/DmRB9YpSitH4pn0pioTNYLFtCV4BHrtvmcuYWvqOR/5CaA97ovmD+X2t6YRIe/W5p2OyKho0QdfKMmGnMylDfaW/f07lWkVeX2BoVYrreUisg1qA/qAvROgGdszWDzS52mdqtMeLYAWAVyYhEf3ktS20Ni7Gwfh/FvxV9OBtWPeWy0s1kyltmHH7qToxd2H4nxTjX4Ie+Pl+Y8n1OtTF8ACGEYwVwLghXA0HgTJQYG3/zFSw/q8F0kpbQZoUNzqmWXggQ380Ef/xnJmQvh+PmYmHxCMm2zbA/UQJ9NcGCV5pgwj2qS7boLhy14fCs9Yrk7npx/7TEArENX9DHtsDAB34oZf9nYWZQKSX4LQcQasvW+dXKqHEa/kOPEvZI98FbcoNq/r+8duySz1usQRy5ttTur2wDLaCUBpRNdNKvFwfdz7SKzQPotI7fpupFVBDIbQgT0GlZLu0MdDkfE2ZxkMpXEMh5o5d465LR/vYVtZiDOTz19a+u52Ag8pWBEvYJ4qmtNOGNvc6MJHrLdew50HQGmUrzHF22fhXsWJ1aDZztbVc4Ydcmu5VmUpUZzdzoMHEUW1ZWxU/Er6uTqaW3d59VV3tRogxtpYyEer7hDE8ZBxP2YtUQMkahH0c3myDqTPdyjcB9pRVtoQRkijzBaOxyGn9sHlFOHxby8xO7B mIsuQPlq gLeEAAY7h3kuVOb7zwf+ubl+BXFpx7+T0fChYAcBCwd6YCqn6Jgvbm48/t7GJFTqga0fYwM/vO2alzFWeQYOaGZKlWCK+P/4K/cMFntRPT6UKIl+Jy45mSJMuWMbVLXvHdJjlLAK1g09G2+eh7YqlVyjKW19CLGaR+lns8sUqWlap9rOWWc7Vx6lps6eoCOKo7utQQ6w8xK/WbNUXP2q7Ac4s1jgeRrGyDFZGzSQar5u5m93z82GsrUyzi+njGNfqaE6ebEmeZR/IH2+gx1oCgeXQUx5dYKI3v19Lannh0IZO9x6cvxmfCMTC0t+0prcozI9eWo4/kMvKajG+Gc/fRYYiOvcs6JIJLCrYg7q+s4Cu8iorTC2+NQaP8A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001473, 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 Wed, Nov 20, 2024 at 11:33=E2=80=AFAM Christian Brauner wrote: > > On Tue, Nov 19, 2024 at 10:45:52AM +0100, Mateusz Guzik wrote: > > quote: > > When utilized it dodges strlen() in vfs_readlink(), giving about 1.= 5% > > speed up when issuing readlink on /initrd.img on ext4. > > > > Benchmark code at the bottom. > > > > ext4 and tmpfs are patched, other filesystems can also get there with > > some more work. > > > > Arguably the current get_link API should be patched to let the fs retur= n > > the size, but that's not a churn I'm interested into diving in. > > > > On my v1 Jan remarked 1.5% is not a particularly high win questioning > > whether doing this makes sense. I noted the value is only this small > > because of other slowdowns. > > The thing is that you're stealing one of the holes I just put into struct > inode a cycle ago or so. The general idea has been to shrink struct > inode if we can and I'm not sure that caching the link length is > actually worth losing that hole. Otherwise I wouldn't object. > Per the patch description this can be a union with something not used for symlinks. I'll find a nice field. > > All that aside there is also quite a bit of branching and func calling > > which does not need to be there (example: make vfsuid/vfsgid, could be > > combined into one routine etc.). > > They should probably also be made inline functions and likely/unlikely > sprinkled in there. someone(tm) should at least do a sweep through in-vfs code. for example LOOKUP_IS_SCOPED is sometimes marked as unlikely and other times has no annotations whatsoever, even though ultimately it all executes in the same setting Interestingly even __read_seqcount_begin (used *twice* in path_init()) is missing one. I sent a patch to fix it long time ago but the recipient did not respond, maybe I should resend with more people in cc (who though?), see: https://lore.kernel.org/all/20230727180355.813995-1-mjguzik@gmail.com/ --=20 Mateusz Guzik