diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2024-05-29 09:39:34 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2024-05-29 09:39:34 -0700 |
commit | 4a4be1ad3a6efea16c56615f31117590fd881358 (patch) | |
tree | 56ce9bc3bd088f6cc186ebdd8a0daacf37b80889 /usr | |
parent | 397a83ab978553ca2970ad1ccdbac0cdc732efd9 (diff) | |
download | linux-stable-4a4be1ad3a6efea16c56615f31117590fd881358.tar.gz linux-stable-4a4be1ad3a6efea16c56615f31117590fd881358.tar.bz2 linux-stable-4a4be1ad3a6efea16c56615f31117590fd881358.zip |
Revert "vfs: Delete the associated dentry when deleting a file"
This reverts commit 681ce8623567ba7e7333908e9826b77145312dda.
We gave it a try, but it turns out the kernel test robot did in fact
find performance regressions for it, so we'll have to look at the more
involved alternative fixes for Yafang Shao's Elasticsearch load issue.
There were several alternatives discussed, they just weren't as simple
as this first attempt.
The report is of a -7.4% regression of filebench.sum_operations/s, which
appears significant enough to trigger my "this patch may get reverted if
somebody finds a performance regression on some other load" rule.
So it's still the case that we should end up deleting dentries more
aggressively - or just be better at pruning them later - but it needs a
bit more finesse than this simple thing.
Link: https://lore.kernel.org/all/202405291318.4dfbb352-oliver.sang@intel.com/
Cc: Yafang Shao <laoar.shao@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'usr')
0 files changed, 0 insertions, 0 deletions