From: Dominique Martinet <asmadeus@codewreck.org>
To: Remi Pommarel <repk@triplefau.lt>
Cc: v9fs@lists.linux.dev, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
Eric Van Hensbergen <ericvh@kernel.org>,
Latchesar Ionkov <lucho@ionkov.net>,
Christian Schoenebeck <linux_oss@crudebyte.com>
Subject: Re: [PATCH v2 0/3] 9p: Performance improvements for build workloads
Date: Thu, 22 Jan 2026 08:23:45 +0900 [thread overview]
Message-ID: <aXFgAcDjjqJc6qhQ@codewreck.org> (raw)
In-Reply-To: <cover.1769013622.git.repk@triplefau.lt>
Remi Pommarel wrote on Wed, Jan 21, 2026 at 08:56:07PM +0100:
> 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 two 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. These two patches introduce a new mount option, ndentrytmo,
> which specifies the number of ms to keep the dentry in the cache. Using
> ndentrytmo=-1 (keeping the negative dentry indifinetly) shrunk build
> time to 1m46.198s.
>
> The third 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-2): 1m46.198s (23% improvement)
> - Above + symlink caching (patches 1-3): 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.
Thank you!
We've had a couple of regressions lately so I'll take a week or two to
run some proper tests first, but overall looks good to me, I just wanted
to acknowledge the patches early.
(as such it likely won't make 6.20 but should hopefully go into the next
one)
--
Dominique
next prev parent reply other threads:[~2026-01-21 23:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 19:56 [PATCH v2 0/3] 9p: Performance improvements for build workloads Remi Pommarel
2026-01-21 19:56 ` [PATCH v2 1/3] 9p: Cache negative dentries for lookup performance Remi Pommarel
2026-02-11 15:49 ` Christian Schoenebeck
2026-02-12 9:16 ` Remi Pommarel
2026-02-18 12:46 ` Christian Schoenebeck
2026-02-21 20:35 ` Remi Pommarel
2026-02-23 14:45 ` Christian Schoenebeck
2026-01-21 19:56 ` [PATCH v2 2/3] 9p: Introduce option for negative dentry cache retention time Remi Pommarel
2026-02-11 15:58 ` Christian Schoenebeck
2026-02-12 9:24 ` Remi Pommarel
2026-02-18 12:56 ` Christian Schoenebeck
2026-01-21 19:56 ` [PATCH v2 3/3] 9p: Enable symlink caching in page cache Remi Pommarel
2026-02-12 15:35 ` Christian Schoenebeck
2026-02-12 21:42 ` Remi Pommarel
2026-02-15 12:36 ` Dominique Martinet
2026-02-19 10:18 ` Christian Schoenebeck
2026-01-21 23:23 ` Dominique Martinet [this message]
2026-02-04 11:37 ` [PATCH v2 0/3] 9p: Performance improvements for build workloads Christian Schoenebeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aXFgAcDjjqJc6qhQ@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=repk@triplefau.lt \
--cc=v9fs@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.