Weekly Edition
Return to the Kernel page
| |||||||||||||
|
| |||||||||||||
Threads and /proc
One result of all the work that was done with improved threading support in
the 2.5 kernel is that threads stopped showing up in the /proc
filesystem. Most people don't miss them, but there are reasons for wanting
to be able to deal with individual threads through /proc. The
main problems have been useability and performance. If you are running a
system with thousands of threads, /proc becomes rather large and
difficult to work with. It's also slow. Ingo Molnar found that, with
16,000 threads in /proc, the top utility took 22 seconds
to work through them all.
The result of Ingo's work, of course, is a patch improving the situation. The first thing Ingo did was to create a "lookup cursor" that gets stashed into the file structure for a process that is digging through /proc. That cursor caches the current state of the directory read operation, greatly speeds the process of reading through a large /proc directory. Ingo also added some new process information so that the thread group leader can be queried for cumulative information on the whole group. Nobody complained much about those changes; there was one other, though, that was a bit more controversial. With Ingo's patch, threads show up in /proc with a period in front of the process ID. Thus, a normal process might be represented as /proc/1234, while a thread would, instead, be /proc/.1234. That change makes it easy for applications to distinguish threads from "full" processes; it also has the effect of hiding threads from a casual /proc directory listing. Unsurprisingly, a number of developers (including Linus) see the period as being a bit of a hack. Wouldn't it be better to put threads in a subdirectory under the thread group leader's ID? Linus even posted a quick patch showing how he thought it could be done. A new patch from Ingo has not yet appeared, but it seems likely that the next revision will put threads into subdirectories. At that point, threads will probably return to /proc in the 2.5 kernel. And /proc will remain fast even with large numbers of threads; Ingo's 16,000-thread top case went from 22 seconds to 0.16 seconds. (Log in to post comments)
|
|
||||||||||||