Recent Linux kernel progress

Linux Kernel: Linux general technology-Linux programming and kernel information. For more information, see the following. During the Chinese New Year holiday, N770 made full use of its function as an e-book reader, which helped me avoid the trouble of carrying computer books such as bricks and stones, I have read many chapters about Linux Networking Architecture. The gains are quite fruitful. At least the writing style of this book is quite in line with my taste. If there is another source code to compare, it may be more perfect.

During this time, a large number of RSS articles have been accumulated. When google reader was opened, as many as thousands of articles have been opened, and some articles have been selectively browsed. For sources with many impurities, in order to save time, mark all the articles as read. Indeed, this time has not happened much. Probably, there are some existing mergers: Sun acquired Virtual Box and Mysql, and NOKIA acquired QT, another is Microsoft's merger of Yahoo, which has not yet been concluded. Vaguely aware that the IT industry's slump may start again, and some friends may have been unhappy about salary increases.

Since the Spring Festival, we have been busy with the release of our products, and we have almost no time to inject fresh spiritual blood into ourselves. It was not until today that we were able to get idle and sleep without fear. After waking up, I still feel dizzy and confused. I felt a little idle. I copied the N770 and turned it over. I found that I had forgotten the lwn I used to check regularly. I started to chew on the article about the Linux kernel, which is really exciting and refreshing. Below I will briefly talk about some of the parts that interest me:

After the classic RCU and RCU which can sleep, the preemption RCU which can improve the real-time kernel performance is also added to the Linux-2.6.25-RC1. The process in the read-critical section of the classic RCU cannot be preemptible. In fact, in the forcibly preemptible kernel, rcu_read_lock/rcu_read_unlock simply disables and enables preemptible by calling preempt_disable/preempt_enable, this means that a high-priority process may be congested without timely scheduling, that is, priority inversion increases the system response time. The RCU can be occupied to solve this problem. It removes the restriction that the read critical section cannot be preemptible, the process that is in the read critical zone where the RCU can be preemptible still does not allow sleep, that is, it cannot explicitly or implicitly call schedule. If the above requirement is met, RCU can be sleep. After turning over the kernel, we found that the real-time semaphore (rtmutex) has been quietly added to a kernel version.

Although in the Linux-2.6.17, splice and tee system calls have been introduced into the Linux kernel as a high-performance API, but the socket splice read operation is delayed due to some reasons into the Linux kernel. For this reason, I have also studied the related emails in detail. I plan to find a time to play, but at present, this is not necessary: 2.6.25-related patches have been included in RC1. I browsed it through the git web interface and thought it was similar to an implementation I considered. I found that it may still have some problems. I will leave it for further research next Monday, I hope I am wrong and it is very likely!

What surprised me most is the current implementation of the spin lock in the x86 kernel. I believe you will be amazed by this exquisite design. The original Article is very good, I will not go!

During Linux kernel development, panic is inevitable sometimes. Because linus always thinks that a good error message is more effective than integrating a developer-oriented bulky kernel debugger, so far, there is no built-in debugger available in the Linux kernel, although third-party patches (such as kdb and kgdb) have always existed, and kgdb has done a lot of work to enter the official kernel, it is hoped that the situation will change in the future. The error message is the only simple (kexec-based kdump is also cumbersome) Way to discover kernel bugs. Although 2.6 kernel has built-in kallsyms, you no longer need other tools to simply read Oops messages, but the messages are usually very long because the screen size is limited, and the keyboard is usually unavailable during panic, so rollback is just a decoration. Softpanic means that the keyboard is still valid when the panic is used. developers can roll back to view lengthy Oops information. In fact, there is another way: by setting the kernel startup parameter console to ttyS0, export Oops messages to the file through the serial port, so that you can see the complete Oops message. You can also use netconsole to send Oops messages to other computers over the network.

The new Kernel Status TASK_KILLABLE was introduced in 2.6.15. Unlike TASK_UNINTERRUPTIBLE, processes in the TASK_KILLABLE status can be awakened by fatal signals (such as SIGKILL, in fact, TASK_UNINTERRUPTIBILE in many parts of the kernel can be replaced with TASK_KILLABLE, so that processes in the "D" status that cannot be killed may not, at least rarely appear.

What can we end? Maybe it's not over!