Google has started opening the implementation of the M:N flow model

Google company suggested for inclusion in the Linux kernel the first set of patches with the implementation of the components necessary to ensure the work of the M: N threading model. Google's initiative is related to the opening of an API developed behind closed doors SwitchTo for the Linux kernel, which provides a multi-threaded subsystem implemented in user space that uses the M: N threading model. The subsystem is used by Google to provide services that require minimal delays. The scheduling and management of thread distribution is performed entirely in user space, which can significantly reduce the number of context switches by minimizing the execution of system calls.

To ensure the operation of this subsystem, the SwitchTo API was implemented at the Linux kernel level, offering three basic operations - wait, resume and swap (switching). For inclusion in the kernel, a code for a new FUTEX_SWAP operation is proposed, supplementing FUTEX_WAIT and FUTEX_WAKE, and provides a framework for building multi-threaded user-space libraries. FUTEX_SWAP can also be used to pass messages between tasks, similar to RPC. For example, at present, to transfer a message between tasks, at least four calls to FUTEX_WAIT and FUTEX_WAKE are required, while using FUTEX_SWAP will allow one operation to be completed 5-10 times faster.

Google has started opening the implementation of the M:N flow model

At present, the flow models 1:1 and N:1 are mainly used in practice. The 1:1 model is used in NPTL (POSIX threads) and LinuxThreads, and implies a direct mapping of a user-space thread to a thread (unit of execution scheduling) at the kernel level. The N:1 model is implemented in GNU Pth, brings thread scheduling to user-space and allows N user-space threads to bind to a single thread in the kernel, without the kernel knowing about user-threads.

The main disadvantage of the 1:1 model is the large overhead of context switching between kernel and user space. The N:1 model solves this problem, but creates a new one - since a thread in the kernel is an indivisible unit of execution scheduling, user threads bound to a single thread in the operating system kernel cannot scale across CPU cores and become bound to a single CPU core.

The M:N model is hybrid and addresses all of the above disadvantages by mapping N userspace threads to M kernel threads, both reducing context switch overhead and scaling across CPU cores. The price of this option is the great complication of the implementation of the thread scheduler in user space and the need for mechanisms to coordinate actions with the kernel scheduler.

Source: opennet.ru

Add a comment