From patchwork Wed Nov 20 11:20:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mateusz Guzik X-Patchwork-Id: 13881063 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 01B7DD6392E for ; Wed, 20 Nov 2024 11:20:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E64A6B007B; Wed, 20 Nov 2024 06:20:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 396446B0083; Wed, 20 Nov 2024 06:20:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 210376B0085; Wed, 20 Nov 2024 06:20:49 -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 F22E66B007B for ; Wed, 20 Nov 2024 06:20:48 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8EC92140BD2 for ; Wed, 20 Nov 2024 11:20:48 +0000 (UTC) X-FDA: 82806229758.15.E5493FC Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf29.hostedemail.com (Postfix) with ESMTP id 3272D120019 for ; Wed, 20 Nov 2024 11:19:36 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=h9BANuQV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732101461; a=rsa-sha256; cv=none; b=dlpMuIq2PcmUfs7z8/6GdD+9lylL4CsIYLTMgX0tTqPt3Cc1ZwPMid/zuRqOEY0GsFZIWL xdHZsXUHj00QFltjMIyBe0OCk2OW+0q25ww2Tyrf9MVKY5hEZQut0VFfJrHBi86Hrfw6Ny xeWO5ytWqXGcAL2Bw9tW/MZsB4OctS0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=h9BANuQV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.43 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=1732101461; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=FYRyH5MT4xu/Wg26DSYNU5aXupUqtlQUxs1/p8n5l1U=; b=zBFT7XKZnlxHZme/GH4hTrRXoY4+xfZKN4vH9MCCaI3X69Aed0fqqpKpkqguI0pDkwfp/w vcGpjau8MukrvjnHrFoVhfLpumOLVfFNuv/BPgy5mq4vQq0R+rNPsWIc8Z4ma5Rr7N4Ynr r9KS/5o7E8tr56XX2hQUzYFAsCcn0Qo= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a9ed0ec0e92so584980266b.0 for ; Wed, 20 Nov 2024 03:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732101645; x=1732706445; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=FYRyH5MT4xu/Wg26DSYNU5aXupUqtlQUxs1/p8n5l1U=; b=h9BANuQVUfh8I95u8qW9Rua0a66cAL5yh55H8IBUs3fzp+aQiGu8y2jfWz0/iPceQ9 u6UPysVYdTUueffBTEv6KKggL3nSSw12MH9Oyuz3EirO8u8X1bAfu+ldgUqyPcvR8Eq4 xU02EdvYkF+PS00CSZ7Lhf77iX9cZEEIKR30sLLMIY/PneyXhLIqy64sX2r2EJUysRHE gE2GV9ZedChEEL9cGAV4Bk3lKJaRpEIYEhRS0OVQA85F7mh2bdcdJ8GmoYqK+U4k8oHq 8yi+nRALmF9pVJhx4XdJUhnaXHUBU1x1IVXD+gbbViVrF2fpsdFi6nF4Kf/8vwFRQrq4 /Guw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732101645; x=1732706445; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FYRyH5MT4xu/Wg26DSYNU5aXupUqtlQUxs1/p8n5l1U=; b=RIUgbRhvXW7HbfHhB2PEBb9IIKBOqbr/HJEkX0bz8iQmtZAdc5tBeed8fM2sLGw13M HadZhuKKSKnMRPO4sShqdbNgkzyArnoc7jwysz5ocL0CONN/xD92RIN43UXlxYEx7vgZ d51hrkIKBjyCqQBx5qKqi9Ij+NYggMnYEPwNBNTQZ42a8lfwmjFLeeUNV2Xg1ohvzFYV xujqwvYGzOPBnVmGbrvdvEk2702HZ55z9JJ0AxnlfoWUohc/ofAInZTlGDvv8+rQgiq9 2VgKD0wUsXnyleB6pOHAFXpnyUCqNshHXw+QgjabnczI3c1ORB9BXgCcUSKcXWWc7uY2 rJwA== X-Forwarded-Encrypted: i=1; AJvYcCVt1s8IC7VAsqZ7sewX+X5juRhqBD/zVALGzQ7/wlDrEoBmiogeb7mJouc+y5DAXaEuHFKGkIOWxQ==@kvack.org X-Gm-Message-State: AOJu0YzGep/rkfSIQKZRW7j9H9KnfAxTGG9OXVKJvIwlNajZKFhhm3xA uoaRPJcPzZdXDCTmTYltcAQaCaoEXtJiM7HfhM938Sgb4xd0o5bf X-Google-Smtp-Source: AGHT+IH+iUZ6CBxj/W2mkhYIPGH2AjoPmpb+wYYabsGQvnI969biIAPnC64kWETIGK4aBBpvLPzzDw== X-Received: by 2002:a17:907:2d08:b0:a87:31c:c6c4 with SMTP id a640c23a62f3a-aa4dd56adebmr216895866b.24.1732101644892; Wed, 20 Nov 2024 03:20:44 -0800 (PST) Received: from f.. (cst-prg-93-87.cust.vodafone.cz. [46.135.93.87]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa20df5690csm758559566b.75.2024.11.20.03.20.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Nov 2024 03:20:44 -0800 (PST) From: Mateusz Guzik To: brauner@kernel.org 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, Mateusz Guzik Subject: [PATCH v3 0/3] symlink length caching Date: Wed, 20 Nov 2024 12:20:33 +0100 Message-ID: <20241120112037.822078-1-mjguzik@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-Stat-Signature: tixn7a8jfdkkh5jtctotcmtqcy396n73 X-Rspamd-Queue-Id: 3272D120019 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1732101576-927803 X-HE-Meta: U2FsdGVkX1/mATDwUzl9Mt4tcLwwqypseIqJph6o1VNavYdL/cIPdW4IeXZOqsvn25FLHZMtkRYck681oa1vrUJ67bqmwqEvmBLs7ycFGTN2nC63yvuuEov0t4rWdGiJj7uQI86l9U2riOVkHA12MYJHPFEurHvA5y9j+PZbFd4Ax/L4Q/g5Q7OgS4mplgQcSAuecA+d+Mbss1PJU6J/43duXj4+t+c/0+g7/9Vfl4RT7FBerMixDRAcv+XnUDH1t4Fgk4FxNDl1q3LZsRrDDzDOWi9dygjpaPGlVKX4EYku1XqVaQOQ5DsTbrE0pu67FzQcyK+YJY6YskgEzKnzCQzz/G45Bi4aE4qREi0BACJqjROjKzN+ZsOii4awLnAuhFPZJxbJvpGN3gR/+zHIxZXFyVDfmDac/0oLZ/1rhrB0aJ3cdNvZUB471XCBLWPiiAC4VnblRJwkeF6bdoPTlYp50DbXoEQRnw9WWng1olq1f834vHKRo+eCMOj0GR02e6Tw1mu62C04uC/NSzKlErTC/tE5MSKhC/F2jH7P7XmV7Vd7EFb505t0DprMZLc5tqztJY+e7teHZ7f2GzWiV5wCpFZtjvwFpK9DBlXl2ntWghMmLdweuD0i8GsG5ymu7PUe02MbRcVxl0kHYpJMb45kbCN2K5H0m0Z8H4/BcQ27OyohPRbQWwE58kDILnWwdSh7TjiHTBWquD6XvdCf1NjzbhVUco5luFpI9YCctMuwSBfYaQ2JQxC6Bqp874E8KFW3iJmOc1hBRq7+7hsTfbbLqEYB5Bwaz6dJvhdzdey84BPZOIAC+W9Wbqb2ZibuxdxtW6T9n1hRaK4j3EplW2+iT/484aczYWMKds9ZrReAId/Aaw/XGcP4+wek4VxsDkh1QqAuntdpfepB/HH0G7a/EZ022sGTA4ZqRkiwCycsQ8ZCukM/zDjwnjNDfGDNa1L588WJBipslqPDbCj 4Cn707JL YCtuZOOkAdvqCxvf1kkyrsN3h1lQnNzWO99KE64a5r/0m3hlH7STDo/ppUw4XD8pvQv22HWoiG74M6SnYgHm6Uab15pr9H6D6Gr0Ds8jzGX5AJsGU0G8GlLtvqTbVB/1ULW4HTTba90tiptK7LPOtqe7ZNkP6Rfn4RW9E7HrrdXuD9yLQIY8269nlndEOoTQHgNEQ9vuCQCcLanw8vTh5ff8ZktKEuiz588K0Jo14u43mVtF72HMA7XEMKjX7n//5vMA7SVkgbrI+Pmy6MjdAvw4gmadCBSw9Mr5VIO3JysIovDtXGfQzeHAqz7r35PNNdXe0iWElJlUZYrH7UatHGLbuwhBUoF2b+mWr6haACe/C+TE= 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: quote: When utilized it dodges strlen() in vfs_readlink(), giving about 1.5% speed up when issuing readlink on /initrd.img on ext4. The size is stored in a union with i_devices, which is never looked at unless the inode is for a device. 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 return 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. To elaborate here are highlights while benching on Sapphire Rapids: 1. putname using atomics (over 3.5% on my profile) sounds like Al has plans to do something here(?), I'm not touching it if it can be helped. the atomic definitely does not have to be there in the common case. 2. kmem_cache_alloc_noprof/kmem_cache_free (over 7% combined) They are both dog slow due to cmpxchg16b. A patchset was posted which adds a different allocation/free fast path which should whack majority of the problem, see: https://lore.kernel.org/linux-mm/20241112-slub-percpu-caches-v1-0-ddc0bdc27e05@suse.cz/ If this lands I'll definitely try to make the pathname allocs use it, should drop about 5-6 percentage points on this sucker. 3. __legitimize_mnt issues a full fence (again over 3%) As far as avoiding the fence is concerned waiting on rcu grace period on unmount should do the trick. However, I found there is a bunch complexity there to sort out before doing this will be feasible (notably there are multiple mounts freed in one go, this needs to be batched). There may be other issues which I missed and which make this not worth it, but the fence is definitely avoidable in principle and I would be surprised if there was no way to sensibly get there. No ETA, for now I'm just pointing this out. There is also the idea to speculatively elide lockref, but when I tried that last time I ran into significant LSM-related trouble. 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.). Ultimately there is single-threaded perf left on the table in various spots. v3: - use a union instead of a dedicated field, used up with i_devices v2: - add a dedicated field, flag and a helper instead of using i_size https://lore.kernel.org/linux-fsdevel/20241119094555.660666-1-mjguzik@gmail.com/ v1 can be found here: https://lore.kernel.org/linux-fsdevel/20241118085357.494178-1-mjguzik@gmail.com/ benchmark: plug into will-it-scale into tests/readlink1.c: #include #include #include #include #include #include #include char *testcase_description = "readlink /initrd.img"; void testcase(unsigned long long *iterations, unsigned long nr) { char *tmplink = "/initrd.img"; char buf[1024]; while (1) { int error = readlink(tmplink, buf, sizeof(buf)); assert(error > 0); (*iterations)++; } } Mateusz Guzik (3): vfs: support caching symlink lengths in inodes ext4: use inode_set_cached_link() tmpfs: use inode_set_cached_link() fs/ext4/inode.c | 3 ++- fs/ext4/namei.c | 4 +++- fs/namei.c | 34 +++++++++++++++++++--------------- fs/proc/namespaces.c | 2 +- include/linux/fs.h | 15 +++++++++++++-- mm/shmem.c | 6 ++++-- security/apparmor/apparmorfs.c | 2 +- 7 files changed, 43 insertions(+), 23 deletions(-)