From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Remi Pommarel <repk@triplefau.lt>,
Dominique Martinet <asmadeus@codewreck.org>
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>
Subject: Re: [PATCH v2 2/3] 9p: Introduce option for negative dentry cache retention time
Date: Wed, 18 Feb 2026 13:56:15 +0100 [thread overview]
Message-ID: <3031269.e9J7NaK4W3@weasel> (raw)
In-Reply-To: <aY2cS77rIL-h-8il@pilgrim>
On Thursday, 12 February 2026 10:24:27 CET Remi Pommarel wrote:
> On Wed, Feb 11, 2026 at 04:58:02PM +0100, Christian Schoenebeck wrote:
> > On Wednesday, 21 January 2026 20:56:09 CET Remi Pommarel wrote:
[...]
> > Wouldn't it make sense to enable this option with some meaningful value
> > for
> > say cache=loose by default? 24 hours maybe?
>
> That is an interesting question, I have seen pretty satisfying (at least
> for me) perf results on the different builds I ran, even with a 1 to 2
> seconds cache timeout, maybe this would be a good tradeoff for
> cache=loose being almost transparent in the eye of the user ? But maybe
> this is too specific to the build workflow (that hit the same negative
> dentries fast enough) ?
Always hard to pick magic numbers. But I would also say that 1s...2s is
probably a use-case specific pick specifically for compiling sources.
When running 9p as rootfs you will also frequently run into libs querying the
same non-existing configuration files and DLLs over and over again. So I would
pick a higher value. Personally I would be fine with anything between few
minutes ... 24h for cache=loose. For other cache modes this could be lower.
/Christian
next prev parent reply other threads:[~2026-02-18 12:56 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 [this message]
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 ` [PATCH v2 0/3] 9p: Performance improvements for build workloads Dominique Martinet
2026-02-04 11:37 ` 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=3031269.e9J7NaK4W3@weasel \
--to=linux_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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.