mirror of
https://github.com/libfuse/libfuse.git
synced 2024-11-27 06:04:27 +08:00
af5710e7a3
On benchmarking metadata operations with a single threaded bonnie++ and "max_idle_threads" limited to 1, 'top' was showing suspicious 160% cpu usage. Profiling the system with flame graphs showed that an astonishing amount of CPU time was spent in thread creation and destruction. After verifying the code it turned out that fuse_do_work() was creating a new thread every time all existing idle threads were already busy. And then just a few lines later after processing the current request it noticed that it had created too many threads and destructed the current thread. I.e. there was a thread creation/destruction ping-pong. Code is changed to only create new threads if the max number of threads is not reached. Furthermore, thread destruction is disabled, as creation/destruction is expensive in general. With this change cpu usage of passthrough_hp went from ~160% to ~80% (with different values of max_idle_threads). And bonnie values got approximately faster by 90%. This is a with single threaded bonnie++ bonnie++ -x 4 -q -s0 -d <path> -n 30:1:1:10 -r 0 Without this patch, using the default max_idle_threads=10 and just a single bonnie++ the thread creation/destruction code path is not triggered. Just one libfuse and one application thread is just a corner case - the requirement for the issue was just n-application-threads >= max_idle_threads. Signed-off-by: Bernd Schubert <bschubert@ddn.com> |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| cuse_client.c | ||
| cuse.c | ||
| cxxopts.hpp | ||
| hello_ll.c | ||
| hello.c | ||
| invalidate_path.c | ||
| ioctl_client.c | ||
| ioctl.c | ||
| ioctl.h | ||
| meson.build | ||
| notify_inval_entry.c | ||
| notify_inval_inode.c | ||
| notify_store_retrieve.c | ||
| null.c | ||
| passthrough_fh.c | ||
| passthrough_helpers.h | ||
| passthrough_hp.cc | ||
| passthrough_ll.c | ||
| passthrough.c | ||
| poll_client.c | ||
| poll.c | ||
| printcap.c | ||