| Message ID | 20240802-openfast-v1-0-a1cff2a33063@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | fs: try an opportunistic lookup for O_CREAT opens too | expand |
> fs: remove comment about d_rcu_to_refcount > fs: add a kerneldoc header over lookup_fast I took both of these into vfs.misc since they're really unrelated cleanups.
On Mon, 2024-08-05 at 12:46 +0200, Christian Brauner wrote: > > fs: remove comment about d_rcu_to_refcount > > fs: add a kerneldoc header over lookup_fast > > I took both of these into vfs.misc since they're really unrelated cleanups. Thanks! I was going to suggest that.
We've had some reports of i_rwsem contention in some workloads. On an open with O_CREAT set, it always takes i_rwsem for write when handling the last component. This patchset is intended to alleviate some of that contention, and to generally speed up opens when O_CREAT is set and the file already exists. I have a simple benchmark that forks a bunch of processes that then do O_CREAT opens and closes of a file in the same directory as their peers. This test runs in about 18s on v6.10 kernels. With this patchset, it runs in about 10s. The basic idea is to do an opportunistic dcache lookup even in the O_CREAT case, which allows us to avoid taking the inode_lock altogether when the file already exists. The last patch does this, but it turns out to perform worse under heavy contention than taking the i_rwsem for write. The problem is that that moves the contention to the parent's d_lockref, which rapidly devolved to plain old spinlock contention. So, there is an earlier patch in the series which changes how lockrefs work to perform better under heavy contention. Locking primitives aren't my area of expertise, so consider that one a starting point for discussion. I also wrote a second testcase that just attempts to create and delete a file in a loop (trying to hit the pessimal case where the fast_lookup never helps). That test runs in about the same amount of time with both kernels. A Linux kernel build seems to run in about the same amount of time both with and without this patchset. Many thanks to Josef for his help with this. Signed-off-by: Jeff Layton <jlayton@kernel.org> --- Jeff Layton (4): fs: remove comment about d_rcu_to_refcount fs: add a kerneldoc header over lookup_fast lockref: rework CMPXCHG_LOOP to handle contention better fs: try an opportunistic lookup for O_CREAT opens too fs/dcache.c | 3 --- fs/namei.c | 57 ++++++++++++++++++++++++++++++++++----- lib/lockref.c | 85 ++++++++++++++++++++++------------------------------------- 3 files changed, 82 insertions(+), 63 deletions(-) --- base-commit: 0c3836482481200ead7b416ca80c68a29cfdaabd change-id: 20240723-openfast-ac49a7b6ade2 Best regards,