On 7/5/2024 3:56 PM, Ma, Yu wrote:
I had something like this in mind:
diff --git a/fs/file.c b/fs/file.c
index a3b72aa64f11..4d3307e39db7 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -489,6 +489,16 @@ static unsigned int find_next_fd(struct fdtable
*fdt, unsigned int start)
unsigned int maxfd = fdt->max_fds; /* always multiple of
BITS_PER_LONG */
unsigned int maxbit = maxfd / BITS_PER_LONG;
unsigned int bitbit = start / BITS_PER_LONG;
+ unsigned int bit;
+
+ /*
+ * Try to avoid looking at the second level map.
+ */
+ bit = find_next_zero_bit(&fdt->open_fds[bitbit], BITS_PER_LONG,
+ start & (BITS_PER_LONG - 1));
+ if (bit < BITS_PER_LONG) {
+ return bit + bitbit * BITS_PER_LONG;
+ }
Drat, you're right. I missed that Ma did not add the proper offset to
open_fds. *This* is what I meant :)
Honza
Just tried this on v6.10-rc6, the improvement on top of patch 1 and
patch 2 is 7% for read and 3% for write, less than just check first word.
Per my understanding, its performance would be better if we can find
free bit in the same word of next_fd with high possibility, but
next_fd just represents the lowest possible free bit. If fds are
open/close frequently and randomly, that might not always be the case,
next_fd may be distributed randomly, for example, 0-65 are occupied,
fd=3 is returned, next_fd will be set to 3, next time when 3 is
allocated, next_fd will be set to 4, while the actual first free bit
is 66 , when 66 is allocated, and fd=5 is returned, then the above
process would be went through again.
Yu
Hi Guzik, Honza,
Do we have any more comment or idea regarding to the fast path? Thanks
for your time and any feedback :)
Regards
Yu
