pts/blogbench-1.1.0 is a benchmark designed to replicate the load of a real-world busy file server by multiple threads of random reads, writes, and rewrites. When running default configuration with multiple parallel threads, hot spin lock contention is observed from alloc_fd(), file_closed_fd() and put_unused_fd() around file_lock. These 3 patches are created to reduce the critical section of file_lock in alloc_fd() and close_fd(). As a result, on top of patch 1, pts/blogbench-1.1.0 has been improved by 22% for read and 8% for write on Intel ICX 160 cores configuration with v6.10-rc7. v3 -> v4: 1. Rebased the patch set to v6.10-rc7 and updated performance results. 2. Updated patch 1 to revise the order of fd checking. 3. As proposed by Mateusz Guzik <mjguzik gmail.com>, and agreed by Jan Kara <jack@xxxxxxx> and Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>, updated patch 3 with a more generic and scalable fast path for the word contains next_fd. v2 -> v3: 1. Rebased the patch set to latest v6.10-rc6 and updated the performance results 2. Reordered the patches as suggested by Mateusz Guzik <mjguzik gmail.com> 3. Updated the fast path from alloc_fd() to find_next_fd() as suggested by Mateusz Guzik <mjguzik gmail.com> and Jan Kara <jack@xxxxxxx>, it is efficient and more concise than v2. v1 -> v2: 1. Rebased the patch set to latest v6.10-rc4 and updated the performance results 2. Fixed the bug identified by Mateusz Guzik in patch 1 with adding rlimit check for fast path 3. Updated patch 3 to remove sanity_check directly per the alignment with maintainer Yu Ma (3): fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd() fs/file.c: conditionally clear full_fds fs/file.c: add fast path in find_next_fd() fs/file.c | 50 +++++++++++++++++++++++++++++--------------------- 1 file changed, 29 insertions(+), 21 deletions(-) -- 2.43.0
