From patchwork Tue Nov 19 09:45:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mateusz Guzik X-Patchwork-Id: 13879531 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 E1C3BD62060 for ; Tue, 19 Nov 2024 09:46:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D4006B007B; Tue, 19 Nov 2024 04:46:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55E606B0082; Tue, 19 Nov 2024 04:46:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4249B6B0083; Tue, 19 Nov 2024 04:46:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 147176B0082 for ; Tue, 19 Nov 2024 04:46:12 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C006E40309 for ; Tue, 19 Nov 2024 09:46:11 +0000 (UTC) X-FDA: 82802363280.14.A65F76E Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf20.hostedemail.com (Postfix) with ESMTP id 64C0A1C000D for ; Tue, 19 Nov 2024 09:45:07 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Va36/UQx"; spf=pass (imf20.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.46 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=1732009509; 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=+Hc3aUwdelvLacRTbdSCz+CvcimyCx26wmG+apt6ADc=; b=hhrnAYr1f/2HMDflCbvgfB+MS/vL/FDen4tHCcmRlTLS/U84k4DQJ7olxZ/AP3aDPf6tPC IuW5Dl6HqewrQd6nWUDWB5EkNhEkx+rETsbelL/QErRl/r56orU8vrG24kbkdhaYRzMFOz Gt0lLVmCbzgC4SQW61PVh68dPR+yxdo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732009509; a=rsa-sha256; cv=none; b=1tmnlv7bPzX04VfCiT6NvMCPa23CPP1gVIN7AItNWHK4SfDot4TmHulPWckPpyCGL7h/e4 ku5gOehlIm/KQDRTvRxX3Q+c5+lOiDh70OleHZMAqySZRr/WHGhkrBR/cjLGIS1Nuiq+yd FtNPSlJEOSfITNKPGc8WSL4lURRB8GQ= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Va36/UQx"; spf=pass (imf20.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5ceca0ec4e7so748703a12.0 for ; Tue, 19 Nov 2024 01:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732009568; x=1732614368; 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=+Hc3aUwdelvLacRTbdSCz+CvcimyCx26wmG+apt6ADc=; b=Va36/UQxXZFBpFVqR69HXT2sp7zdjGx2+AqUgdiIEdmkIJbBNfq0uurnunjkdA+rd1 iLCSsM2YSVnIa/YMUcir+MJuKH41DaiL8wywmmMtI2ljgPsPp+ol18lx4SZZbgW4Lh13 1ReQI9+Zp3kwdJc/G5M+UcXG1kFf1u5hVirNkO4Ni3BmP+16UC7eJW3oSJUmzOcdhSD2 u7mw3vbxgWypzBpdoJCNgAHFIIibponweS550Pr/gMjqP9SBbV7NhxDLsSE9xlbyP0Oj znJBNSNJ0n+gT0c+tCVYt74xhsEYq3o2YFTnr7mwboE94g7HT4rVLo9EQkwMCNXI55rU pFvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732009568; x=1732614368; 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=+Hc3aUwdelvLacRTbdSCz+CvcimyCx26wmG+apt6ADc=; b=gmnG0o1viq1lHvOz13CtgqSyhzhGIzYAlikp1m+ByerTMbYuQiBKDnaoSuv+xP0fze ESQi+cTtmn8zsjZQqfzEKdsHcin83e60hEa1WYiQDQJEv+XR90busdK6Q4iIVil/QH+j W9qa0bAdval2zp4aE0vU+ElqV1+2xhV7w2HzgGeRCPGbpQ4o6OmJ4TbFpSkVVQJqGgJr Xrlr1l8W5TicpQPB0Rk+1orWqKlr1urdJAahIKyb1mHuIgMqdukih/LRTRQcEamhfTAy PagqW4IqLi+u+mHEypAmMIBAiLZSM9GVFLeubCAtvdNQkK4rCEnrXUSUy5P5Zm8kfffC ca9Q== X-Forwarded-Encrypted: i=1; AJvYcCWcNBhjQzxU/TyQOarjqIAb75p1Uzd9WfRqR7Ry2bwVdw7gVIcixy/9L64CiO/1d7G0ZOjQ7n2iuw==@kvack.org X-Gm-Message-State: AOJu0YyH7k0U4xyldWhNhvWJjXJEcb+mdIjnKUbuYBsOy9nvTwb927O/ nqm8og0a3hHRxmP+CjUvpKjHF/wzS0A3bMkkTqBAeNWUqBMx5017wEz6yg== X-Google-Smtp-Source: AGHT+IHqrKS0bZ4q6aqBkVlhpgYvXu06WffntfdniQvb1WE0B0SGLHtxSu2F+xMgqGgglqraP1bEUg== X-Received: by 2002:a05:6402:1e94:b0:5ce:af48:c2cc with SMTP id 4fb4d7f45d1cf-5cf8fcdfb82mr12600726a12.27.1732009568023; Tue, 19 Nov 2024 01:46:08 -0800 (PST) Received: from f.. (cst-prg-93-87.cust.vodafone.cz. [46.135.93.87]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cfcb3edce9sm1821154a12.35.2024.11.19.01.46.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Nov 2024 01:46:06 -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 v2 0/3] symlink length caching Date: Tue, 19 Nov 2024 10:45:52 +0100 Message-ID: <20241119094555.660666-1-mjguzik@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-Stat-Signature: r75o8daacydu9iyje3iuztr99fr3jk9f X-Rspam-User: X-Rspamd-Queue-Id: 64C0A1C000D X-Rspamd-Server: rspam02 X-HE-Tag: 1732009507-453601 X-HE-Meta: U2FsdGVkX19I1huBjhWE7uunFNzpZGv/8EgytpBZ+lgYBdcwKiNy6oLV1IM4wtjn1wwzsGCaTGVEdv2AHHJF+QBB6r6uc1Sl28QRHqA1WSTQMLvWJ5qJxbmbgboIzdrBbftUKwlTSynzRH3FfIfw/EyZEfKm3p67fxF/JzPFvMFMttb6jifjW16c3LFVkm1Auhmx6wJh0IjMwPW+Aq7WmPegkRJyg5ArsyR9lKkmyxr67StXU0TBo0nTLLr+VkV77yZ6sIbjtTA4SNPyWuK2nolWfiPo/8Zuwnm8e3E54d2V0f2vZ72u/TQrPX3egM/jJb9YpIzppnqVNaxvV4VtOOZ0XSrgcqBT2zzGFa4Tzh/zaeAkUKQh8fFsZHzZ2yMf9114F4tM0mPSTYXA1v60C5+clv6cpZWgqnjaz4XfvVvjcrOTNnbUeDkvCwO+if8JOsdYceYkz9o9328Zu9lrLsGiTHBmN07/gkKtouOtaT75a0cHy+AUOXgUPFucxNPPD0TAZskBusf6o9l4I16fV+UfUVePIDMmB/rOC/Q5n4B/Kg+2oZQtLq1n4tYpvdeBKfQ10kUOw/ly3kqPfi36t/hWkR5Tm8bM6rprVR8uYBmDYcfNTpoelR7jw+bjRoTBdrIK9mI1JUpYeJgLQbsU/MIQthKXrFn7PWooquY/XLlMD3YU0kWYRwkmXTsH2I16Ko7f0qrERV2WKIdltc2ayTgjZBX3t9CzXyxzJhYFNmhdHTirhjZUOV1mwkOcRJffg2+rWiA1OjsUlHIsXmXgAvKlUPaUZN8RgdEuUdWdjioLzB36eKmbCWbkUkSux6CQIaeaJLEA7hIUjSBgVS7YVyFBCDnqutoEjyTcucj8T5y6q2Nap7JZ+dHyZqfUnbbgrmREk14Jm/L9D7+gr97V1/pZlyRwRIWsh8JPRR8WMGn4W+hVL6MVlAwFNYiAmethyuEl+ZmST3TXm7ycjYh IaHUuXMJ 1ktDBX1g7VDdZ+C35UFWIDL+qFrwRNIX+4SAjqa/aD/ar415ANFZ9xrilYn8WEhSI5qQJKYJwm1/AA/p/mF8tamab0QOND5hqfH4smPQG+JqRTzdhZOoOYizar+T62DDJ8ixPDvQIloW1Tx5cYwuuLpkD2lsMu0WQCqalENMOxxJBfg9KUYEQN/B3tba6M/RizcWdFV0bXT7M57J/jbCA8+I7ECn5L7lmTD5st6ipJhv4X/kBoGoSqmpnF/C97hbOe2Zcanbygl3FoCUiU3fOAXQE/FOjEkgFZrv3et/Q4Ctdxx/B9Hj/jQwnLyiGJuE5jjE63qMe9L+oK2u4jgytDP0p1f0NkrWsjQYnU/bz6AtYPMc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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. 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. v2: - add a dedicated field, flag and a helper instead of using i_size - constify i_link 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 | 12 ++++++++++-- mm/shmem.c | 6 ++++-- security/apparmor/apparmorfs.c | 2 +- 7 files changed, 40 insertions(+), 23 deletions(-)