Making Signals Scale in Multithreaded Apps


One Line Summary

An overview of the Linux kernel scalability bottlenecks relating to signals in multithreaded apps.


Currently, the ‘siglock’ spinlock (which is shared by all threads) serialises all signal activity within a thread group. This means that even if thread A sends a signal to thread B, thread C cannot send a signal to thread D until thread A has released the siglock. Furthermore, no thread can receive a signal from another thread until ‘siglock’ is free.

This siglock is a huge point of contention and completely prohibits any sort of parallelism during signal generation/delivery in multithreaded apps.

One solution to this problem is to introduce another spinlock that protects the per-thread pending signal queues, instead of the shared ‘siglock’ which currently protects both the shared and per-thread pending signal queues.

This presentation will discuss the design and implementation of a much more fine-grained approach to locking.

As the first version of this patch series has already been posted to LKML, these changes will likely have been integrated into the kernel by the start of LPC.


kernel, signal, scale


  • Matt Fleming



    Matt Fleming works on the Linux kernel at the Intel Open Source Technology Center.

    He has previously written kernel code for a variety of architectures but currently spends most of his time optimising the kernel to scale better.