I had something like this in mind:Hi Guzik, Honza,
diff --git a/fs/file.c b/fs/file.cDrat, you're right. I missed that Ma did not add the proper offset to
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;
+ }
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