From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from e3i670.smtp2go.com (e3i670.smtp2go.com [158.120.86.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 56DF930DEB6 for ; Fri, 27 Feb 2026 08:16:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=158.120.86.158 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772180170; cv=none; b=WvhRf/520ZH3BRI9sjwNwpRO1Qhalo9WTQ3pgu1/alLTyDqma+yfntDVPSHGJUOwb8AzXfVOz0UObwKQcBDO4gxHZqm0UCmOxr3eDByIZL/wKl2o+9q0WHSr/SUr4MIYkExobW+K2LoWeU8ZkEPhjfvZH70dRhbkMDHZnw4ARTY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772180170; c=relaxed/simple; bh=cPPm/LxTGin0WTZSGhPPnZCVw13guVicL/ExTN0AdKQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=o8NwQH1NbMmmcrUbZ4s/jEjzum/m6VKkVWNK9pu+htTwuFwwWsPjJ+gIb/l3NIiWpeUbXZGuaC032sR0U8PbOOJp8RRJEbx7zdXZ6tz/2VwKhwd+uIF5KZ8UtyydW/oW5O9bx2IYqaSGcJ7P18kqRLlJuGjLV5IzQZ/TemX8Cww= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=triplefau.lt; spf=pass smtp.mailfrom=em510616.triplefau.lt; dkim=pass (2048-bit key) header.d=triplefau.lt header.i=@triplefau.lt header.b=kzvEOLnm; arc=none smtp.client-ip=158.120.86.158 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=triplefau.lt Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=em510616.triplefau.lt Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=triplefau.lt header.i=@triplefau.lt header.b="kzvEOLnm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=triplefau.lt; i=@triplefau.lt; q=dns/txt; s=s510616; t=1772180166; h=from : subject : to : message-id : date; bh=7q4ck1jSkFF2a7txlvqCLczhxHn0jMNnagqqcLi9F7A=; b=kzvEOLnmJZZhffVxD8hwgyAp1Vsk39CFoisNVN6n4LDfFo07Ynf8BdJTGNbp9e4tJuWKM 5i8nVebVcdiLmZ4UJrcyFzT8a7P0dEUeNpwiUq3gZz/gO1k6xgN+/X/BLiNgok8bCj/tnRd t7CUdfPbaE1kjB4M3ZsRGKsAFfyfS+CkMY9Ap0UUJGMiBvG2/HZmWZAz14YwMkvllmCrWoP eNbnPCVCJpLHulXsBbw2h/Ix9Pj2feM6AOoRSZUTCVLSspjNskRVNeLtq+JvC+UfffEmThr uczyWA+prfGe7MKO4waEqKot3TTSROcJKqHj7+VfU4/FlLdLcX8HFLdffQhQ== Received: from [10.12.239.196] (helo=localhost) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.99.1-S2G) (envelope-from ) id 1vvt0t-FnQW0hPlFgP-nUw0; Fri, 27 Feb 2026 08:15:55 +0000 From: Remi Pommarel To: v9fs@lists.linux.dev Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , Remi Pommarel Subject: [PATCH v3 0/4] 9p: Performance improvements for build workloads Date: Fri, 27 Feb 2026 08:56:51 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Report-Abuse: Please forward a copy of this message, including all headers, to Feedback-ID: 510616m:510616apGKSTK:510616siJYhIGm7G X-smtpcorp-track: ozovhNJu47e7.-AO_KCyRnj6f.gtgtSwFkEtF This patchset introduces several performance optimizations for the 9p filesystem when used with cache=loose option (exclusive or read only mounts). These improvements particularly target workloads with frequent lookups of non-existent paths and repeated symlink resolutions. The very state of the art benchmark consisting of cloning a fresh hostap repository and building hostapd and wpa_supplicant for hwsim tests (cd tests/hwsim; time ./build.sh) in a VM running on a 9pfs rootfs (with trans=virtio,cache=loose options) has been used to test those optimizations impact. For reference, the build takes 0m56.492s on my laptop natively while it completes in 2m18.702sec on the VM. This represents a significant performance penalty considering running the same build on a VM using a virtiofs rootfs (with "--cache always" virtiofsd option) takes around 1m32.141s. This patchset aims to bring the 9pfs build time close to that of virtiofs, rather than the native host time, as a realistic expectation. This first three patches in this series focus on keeping negative dentries in the cache, ensuring that subsequent lookups for paths known to not exist do not require redundant 9P RPC calls. This optimization reduces the time needed for the compiler to search for header files across known locations. The two first patches introduce a new mount option, ndentrycache, which specifies the number of ms to keep the dentry in the cache. Using ndentrycache without value (i.e. keeping the negative dentry indifinetly) shrunk build time to 1m46.198s. The third patch enable the negative dentry caching for 24 hours by default on cache=loose. The fourth patch extends page cache usage to symlinks by allowing p9_client_readlink() results to be cached. Resolving symlink is apparently something done quite frequently during the build process and avoiding the cost of a 9P RPC call round trip for already known symlinks helps reduce the build time to 1m26.602s, outperforming the virtiofs setup. Here is summary of the different hostapd/wpa_supplicant build times: - Baseline (no patch): 2m18.702s - negative dentry caching (patches 1-3): 1m46.198s (23% improvement) - Above + symlink caching (patches 1-4): 1m26.302s (an additional 18% improvement, 37% in total) With this ~37% performance gain, 9pfs with cache=loose can compete with virtiofs for (at least) this specific scenario. Although this benchmark is not the most typical, I do think that these caching optimizations could benefit a wide range of other workflows as well. Changes since v2: - Rename v9fs_dentry_is_{expired,refresh} to ndentry - Some grammatical fixes in couple of comments - Rename the negative cache mount option to ndentrycache. Using ndentrycache without value enable infinite caching while ndentrycache=