Another Kernel Optimization Being Worked On That Can Help IO_uring Performance
It's always great starting off a new month seeing new work on low-level kernel optimizations.
Jens Axboe, Facebook engineer and maintainer of the Linux block subsystem and lead IO_uring developer, sent out a new optimization today. The optimization is to decouple TASK_WORK TWA_SIGNAL handling from signals.
Axboe explains of the change, "Users of TWA_SIGNAL need to have system calls interrupted and go through a kernel/user transition to ensure they are run. This currently works well from a functional standpoint, but it is heavy handed on a multithreaded application where sighand is shared between the threads and main process. Adding TWA_SIGNAL task_work on such setups need to grab the sighand->lock, which creates a hot spot for otherwise unrelated task_work. This adds TIF_TASKWORK for x86, which if set, will return true on checking for pending signals. That in turn causes tasks to restart the system call, which will run the added task_work. If TIF_TASKWORK is available, we'll use that for notification when TWA_SIGNAL is specified. If it isn't available, the existing TIF_SIGPENDING path is used."
For end-users, what matters is the possible performance benefit. When Axboe was testing with a simple IO_uring implementation, with this patch he went from seeing 1.38 million requests per second up to 1.67 million requests per second. Not only was the performance up by about 20%, but the CPU usage was also lower with the patched kernel.
This is in part a performance regression fix after it was spotted from Linux 5.7.15 to 5.7.16 resulted in a performance drop and greater utilization following a TWA_SIGNAL change.
There is the patch for those interested. This is already the second spin of the day as some issues were raised from the first patch. It also looks like there are some technical details to be ironed out with the second iteration, but hopefully it will be squared away in short order.
Jens Axboe, Facebook engineer and maintainer of the Linux block subsystem and lead IO_uring developer, sent out a new optimization today. The optimization is to decouple TASK_WORK TWA_SIGNAL handling from signals.
Axboe explains of the change, "Users of TWA_SIGNAL need to have system calls interrupted and go through a kernel/user transition to ensure they are run. This currently works well from a functional standpoint, but it is heavy handed on a multithreaded application where sighand is shared between the threads and main process. Adding TWA_SIGNAL task_work on such setups need to grab the sighand->lock, which creates a hot spot for otherwise unrelated task_work. This adds TIF_TASKWORK for x86, which if set, will return true on checking for pending signals. That in turn causes tasks to restart the system call, which will run the added task_work. If TIF_TASKWORK is available, we'll use that for notification when TWA_SIGNAL is specified. If it isn't available, the existing TIF_SIGPENDING path is used."
For end-users, what matters is the possible performance benefit. When Axboe was testing with a simple IO_uring implementation, with this patch he went from seeing 1.38 million requests per second up to 1.67 million requests per second. Not only was the performance up by about 20%, but the CPU usage was also lower with the patched kernel.
This is in part a performance regression fix after it was spotted from Linux 5.7.15 to 5.7.16 resulted in a performance drop and greater utilization following a TWA_SIGNAL change.
There is the patch for those interested. This is already the second spin of the day as some issues were raised from the first patch. It also looks like there are some technical details to be ironed out with the second iteration, but hopefully it will be squared away in short order.
2 Comments