Application 2.6 kernel hyper-threading Mode

Application 2.6 kernel hyper-threading mode-general Linux technology-Linux programming and kernel information. The following is a detailed description. For most application software developers, most of the differences between Linux 2.4 and 2.6 kernel families have no direct impact on them. Most kernel changes only aim to improve system performance. But there are also exceptions. For some application software, kernel and system changes have a certain impact on their promotion and management of other processes and threads.

The 2.6 kernel provides users with a new and improved hyper-threading mode. This mode is implemented through NPTL (Native POSIX Thread Library. The adoption of the new hyper-threading mode has extraordinary significance for developers, system runtime libraries (such as the gnu c library), and shared application software libraries. This article will introduce basic hyper-threading concepts, discuss existing Linux hyper-threading modes, and highlight how to modify existing multi-threaded applications in the 2.6 kernel.

Hyper-Threading Technology

In a multi-process operating system such as Linux, generating another process by one process is the most basic concept. The most typical example is a shell program, such as a Bash shell program. It is a standard Linux Command Interpreter. The shell program executes the corresponding application based on the user's command. It can start multiple commands directly and wait for them to complete. It can also execute multiple commands separately and simultaneously.

A process can usually call a group of fork () and exec () functions to generate a new process. The initial process calls the fork () function to generate a sub-process. The sub-process inherits the entire execution environment of the parent process. The fork () function calls the process ID (PID) of the sub-process to the parent process, and also includes the PID in the sub-process. Then, the child process uses the exec () function to call other commands and change the inherited execution environment. At the same time, the parent process can exit quickly or wait for the child process to return to its initial state.

Linux hyper-threading Mode

The standard Linux hyperthreading library of all versions earlier than Linux 2.6 is called LinuxThreads. This library works with the gnu c library not lower than GLIBC 2.0 and is compatible with POSIX.

During the compilation of LinuxThreads and Native POSIX Thread Library (NPTL) source code, the main libraries generated are libpthread. so and libpthread.. Therefore, LinuxThreads and pthreads names can be used in the past. However, after NPTL is introduced, the two are easily confused. This article uses LinuxThreads and NPTL to clearly differentiate two hyperthreading libraries and their functions.

LinuxThreads has different performance, scalability, and availability limits. LinuxThreads uses a compiler to set the number of threads that can be generated by a single process. In addition, it uses a process manager to coordinate the relationships between all threads generated by each process. This will greatly increase the number of threads to establish and eliminate occupied resources. Although almost every thread has an independent process ID, signal processing is still completed in each process. For various reasons, during the implementation of LinuxThreads, the number of threads simultaneously generated and working is often limited. These factors include the asymmetry between the kernel and user space threads, lack of thread synchronization primitives required for Inter-thread communication and resource sharing.

Another hyperthread mode in Linux is IBM's next-generation POSIX thread (NGPT) project. It is an external hyperthreading library that works with the LinuxThreads suite. However, it can provide additional POSIX support and better performance than the standard LinuxThreads suite. The NGPT kit can be used in Linux2.4 and earlier kernels. Due to the generation of the new superthread mode, its application scope is getting smaller and smaller.

Since the emergence of the 2.5 kernel, NPTL has gradually replaced LinuxThreads and NGPT. NPTL provides high-performance hyper-threading support for Linux systems, basic features required by multi-threaded enterprise application software, and high-capacity, high-load network and mail servers. NPTL development is part of the 2.5 kernel development process and is integrated with Linux runtime components (such as GLIBC). NPTL with many advantages is the future development direction of Linux threads.

Some Linux system manufacturers (such as Red Hat) have begun to append NPTL to earlier versions of the kernel, and even use an environment variable to create a hyper-threading environment for specific optional processes. In systems that support this function, you can use the following command to set variables:

# Export LD_ASSUME_KERNEL = 2.4.1

For existing applications that originally rely on the LinuxThreads model, it is a clever way to continue working in the NPTL environment, but it is also a matter of privilege. To better utilize NPTL's design and performance advantages, You need to upgrade the code of existing application software using hyper-threading mode.

Application Software Re-Compilation

Although many applications do not need to be re-compiled during the porting process from the 2.4 kernel to the 2.6 kernel, The NPTL additional technology of most multithreading applications needs to be slightly modified.

Those applications that need to be re-compiled may be affected by upgrading the Compilation Program. These compilers are generally included in the 2.6 kernel-based Linux suite, such as the TimeSys Linux system. TimeSys bundled C and C ++ compilers of GCC 3.3.2 with 2.6 Reference Distributions, and used the upgraded version of binutils to make up for the shortcomings of the standard Linux tool chain.

Using a 2.6-Based Kernel does not mean that you have used NPTL automatically. To determine the hyperthreading library used by the system, you can run the following command to check the environment variable GNU_LIBPTHREAD_VERSION, as shown below:

# Getconf GNU_LIBPTHREAD_VERSION
Linuxthreads-0.10
If your system uses the NPTL, the command wowould
Return the value of NPTL that your system was using,
As in the following example:
# Getconf GNU_LIBPTHREAD_VERSION
Nptl-0.60



If you are creating a toolchain for the 2.6 kernel, you must be sure that the "toolchain" with NPTL technical support has been established on the 2.6 kernel ". In addition, users also need newer C Language Library source code. For example, if you are creating a GBLIC with NPTL support, you must use the GBLIC source code of version 2.3.3 or later. The process of NPTL support for GBLIC is very similar to that of LinuxThreads support. The difference is that when GBLIC is set, the "-- enable-add-ons = nptl" option is used instead of "-- enable-add-ons = linuxthreads ". You also need a new version of GCC (3.3.2 or later) and binutils (2.14.90.0.7 or later) that supports the CFI instruction ).

Generally, if your application software is compiled with GCC of an earlier version, you may notice the differences in alarm information, source code size, and so on. In addition, the options provided by the GCC compiler and the remaining toolchain are also different. When you recompile embedded application software, you must understand the potential trend of increasing code size. Users may need to make full use of additional or new optimization options to continue to adapt to existing application software in an environment with limited resources. The newer version of GCC can adapt to various C or C ++ specifications and improve the requirements for application software code. In general, the new alarm information obtained from upgrading and compiling programs is very useful to eliminate potential defects.

Update application software for NPTL

The 2.4 kernel hyper-threading support and NPTL support changes provide a broad room for improvement in design and performance. In the 2.4 kernel, NPTL and POSIX specifications are much more adaptive than those of LinuxThreads suites. NPTL also supports functions such as mutexes. Finally, NPTL is more effective than 2.4 kernel hyper-threading support.

During NPTL porting, you need to make more complex modifications to the application software logic. These modifications are related to NPTL support for POSIX signal and signal processing. LinuxThreads implements General Unix threads, but it is limited by various implementation details. Because NPTL is a POSIX-compatible hyper-threading implementation solution, it performs well in inter-process signal processing and inter-thread signal processing. In NPTL, signals can be transmitted from one thread to another, not just between processes. You can also use parameters to transmit information between threads.

When using NPTL, you also need to modify the existing code that identifies a specific thread. In LinuxThreads, each thread has a unique process ID (PID ). Currently, all threads in the parent process share the same PID. Therefore, the getpid () function returns the same PID for all threads in the process. In NPTL, the thread ID of a thread must be unique during use so that each thread can be correctly identified.

Modifying the thread ID and process ID also means that the process generation method needs to be implemented for the thread now. For example, the exec () function can currently operate on threads, so a thread can inherit the caller's PID. Only when the entire process ends does the parent process of the multi-threaded process know that a sub-process has been executed. Thread changes also affect fork () calls. For example, a function registered in the pthread_at_fork () function cannot continue running when vfork () occurs.

In addition to modifying the internal component of thread recognition, NPTL abolished the management thread concept of LinuxThreads and simplified the relationship between processes and threads. These may need to make appropriate changes to the application.

Finally, using the new hyperthread library means that some hyperthreading functions that can be used in LinuxThreads cannot be used in NPTL. For example, the pthread_kill_other_threads_np () function cannot continue to be used. This function activates the exec () function that is compatible with POSIX. In NPTL, the exec () function cannot be compatible with POSIX.

Summary

Modifying the kernel running on a computer is not an easy task, but it is not an impossible task. In the above five articles, we will focus on the main problems encountered in 2.6 kernel settings, upgrading hardware drivers, porting desktops and customized systems, and upgrading application software. TimeSys's 2.6 Reference Distribution is the first Linux suite for PPC systems. High-quality commercial software such as TimeSys's TimeStorm IDE and TimeStorm Linux System Development Kit (LDS) can help us to transplant all Linux kernels, hardware drivers, and applications. In addition, they can help us configure the system to take full advantage of the 2.6 kernel, upgrade kit, Threading Technology and other software technologies.

As the most dazzling star in the open system movement, Linux is actively involved in the revolution of the software industry. As the core of all Linux systems, the Linux kernel continuously introduces new technologies to improve performance, scalability, technical support and availability. 2.6 The kernel expands the application scope of the Linux system. It can be seen everywhere from PDA, process control system, set-top box to Enterprise Server. The cost, power, and technical support advantages of Linux systems are more obvious in today's commercial market and rapidly developing technical environment.