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 7D861D63923 for ; Wed, 20 Nov 2024 10:33:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 097436B0085; Wed, 20 Nov 2024 05:33:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0473D6B0088; Wed, 20 Nov 2024 05:33:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E81D86B0089; Wed, 20 Nov 2024 05:33:33 -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 C77296B0085 for ; Wed, 20 Nov 2024 05:33:33 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 56FCE1C727E for ; Wed, 20 Nov 2024 10:33:33 +0000 (UTC) X-FDA: 82806109260.03.9222C84 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf12.hostedemail.com (Postfix) with ESMTP id B58EC40013 for ; Wed, 20 Nov 2024 10:33:08 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Azh29eYh; spf=pass (imf12.hostedemail.com: domain of brauner@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732098609; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XcAw/Jtiz19qX+nYva/RLiRPdQLrUSUl2Q+B++RU3m4=; b=Z5x0OX6nmiI06XiPIQb1zzu/ACJVzCyD0Fqo2h0vzTzNi9Z+B4nTC+IQXgLG3rpd7qb1Uk gUbmtCy0yUAxhWTgXCioxdMVVS/FUmh4cEgL8bqEe3b4DQSbEK2uRYs2HV6wP23oulhcc8 ecUS3MozL0PF/jvfQv5pe7WY1EBIcLM= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Azh29eYh; spf=pass (imf12.hostedemail.com: domain of brauner@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732098609; a=rsa-sha256; cv=none; b=k6MHiAh2otGs4hgrm3frUIfFKrWmRK2WEvrAW4NdQqWswNkLRmb5uctCLA1On8HD/OgIX/ tPQPToOYWcSZ1c7xQQiZ86cWheu3wGW5ZejDyVjZGDx717kF/tyRFH7O/OL0tFAevVVzF9 xosYkoTi2TdQLxbyf/QK1MV8AhVHIQI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 66D23A42E62; Wed, 20 Nov 2024 10:31:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1FCDBC4CECD; Wed, 20 Nov 2024 10:33:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732098810; bh=pP8qSG+oupMtkwIy7hIPfIrFfr0X4ixyagHCt04slCk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Azh29eYhGMZUKKlu8Y18syyzvqyK9GloDzu+mMA+FEGu6cQXmGo7JmQuezhyiK6kq SODz0W+jLlFcuZxhHFP6b/3sj5lEfKVEqj5h2D/0LZ+zsm87Y0/nwMuPcdATBd+Tv1 cdhYhwhXq37kz1+bHgSAwWoCvOw5Cx2RoUO1aB1qTTiTPYQHiTgBUK80dOmmdDrvtC zG29/7zQeyJfuf6l7Czi54YykUmAgVp+2fUdPmpRyLjiDbwijB68qbL/+PrwDzSdT4 9R+fPNbhHLS2biwsON5rVXjoZnwm6wR9OyPnAa28QuSz3RyMaFKe2XCF9UspI+Zj8t YMKoVnsQ6gRVA== Date: Wed, 20 Nov 2024 11:33:25 +0100 From: Christian Brauner To: Mateusz Guzik 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 Subject: Re: [PATCH v2 0/3] symlink length caching Message-ID: <20241120-werden-reptil-85a16457b708@brauner> References: <20241119094555.660666-1-mjguzik@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20241119094555.660666-1-mjguzik@gmail.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B58EC40013 X-Stat-Signature: 54dibpox1yywntfpy5ssgk1m6denqke8 X-Rspam-User: X-HE-Tag: 1732098788-104957 X-HE-Meta: U2FsdGVkX18uuw+33o+qQWGqvlsSYWc7oh4fJaGiWa56bqaZ1ZrVjfLDGQEz0cIgRL8y0ZnPzky0TarRrLVDYoSg2C+3k1ZwhKEe6c5rwD1F5FYWdJedaUniQH2T+zTYQZRPo0NdqWfpUAHEXKrnj7eWkxqtzErbzsuVHioNfHUhRaTp31zgdptPJ2/20UiSyTrYE5y6LPdT0YXjqrpzvdwxUf0e3x1wNVnjm6kqPbstkXD50Egeal+FTqw0DzyCo0B+CEjmQA4IOWlGElJ6XbUmp2xI9DnzcjGhUFQatWtu3U1dlGV6c31qHU1jxFD0yweJrwvBPkTBPuKCPkfhgIUGq952t6m9SRM/ceJviXp6I/zHgJbdv4g72+fSJ94dNozfr10eNMcjYTpHxUToBf5LrekRTix0F0d+3PhSuLYb6zagWpuz/eCy+BOI86mE4dDRv0MhxDggIW0/EcbUEPAE30T59So8e3VGOObHHlO2X5mCVl+aN+Q6hbA5eD1WVDJMJPewmgUw5QdmYqZ6CLj8yJQByDhmC426DIipitlKHpuyMb7u0FScLTA/M3E7sWTEik7YoJhfjRWUS8KdjcslLnKJs3vvgVj2/xJceUtfzoBQJVMqKL6nbk+BC20FmE0lo0BWFId+pRAU2s27d9ANPE+RDcEx/5dK6Z17+CtNnIyluTrAmFuRvGUznVy2UzPyxny/pbpQyHQVDsbhTZliZVHkktQezoJnmloTgFZma8TgMt/W5bqsoTOmdRtTllI6a7rRk9kEtcK5FWH9oO598NXZi64KVFKg2bzuPTCXdJ4Sasixm/mJ3+bvVbNQ8zGAOqjFY4y2DdfGnU7Tv+O4N1sENve+0O8cW0BxL28rRx8Ihr7EIQSjrrwzPmxm3sFSBuBbssWyj9qzyzRw/Rp37/8zLm27BXVbR5Ae4DfdcGUwE4+wLzVia6goyknyujN1KMgmneXCJ33G/qh 2GnQrkOG oWB7So8dwegNunXOwITi1LfskHQWomtnEWo8s0OhZqLZifW/70s1gcY5ATrL25L8GByX2N2wMDOV328Nx0CjQjSIbYzhQN1i2m45NHhitwZzmzUttJ1e1bYNNhEb9rCVpRHqWMHKjkOXy6KeEPEURW+V2UUU4wHRC1QO1AmExAKfxs0Z4L/O89YgV2yG0MNtl+a579W923P6Z7CJ9oeimC9po2VGLNGmMrlw2+2akWjWCC3aBuOPo3YX7jpZncNnx53dleaugqNC6k2yPDtxydy8fK1XGDqf5vdm73idgjhJMSik= 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: 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 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. 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. > 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.