Too many threads? [LWN.net]

In a discussion of problems in the current request_firmware() interface (discussed here last May), it was noted that firmware loads sometimes happen too slowly as a result of latency in the workqueue mechanism. The firmware interface uses the default workqueue, meaning that its tasks can wait an unknown amount of time behind other users of that queue. In some situations, at least, it seems that this delay can be too long. So a patch was posted which sets up a dedicated workqueue for firmware loading.

Creating one's own work queue can help with the latency problems, but it also loads the system with another kernel thread for each processor. And some people are starting to get a little unhappy with the number of such threads in 2.6. They are proliferating a bit; a quick check on your editor's mighty dual Pentium 450 system (running -test3) shows some 21 of them:

    2 ?        SW     0:00 [migration/0]
    3 ?        SWN    0:00 [ksoftirqd/0]
    4 ?        SW     0:00 [migration/1]
    5 ?        SWN    0:02 [ksoftirqd/1]
    6 ?        SW<    0:00 [events/0]
    7 ?        SW<    0:00 [events/1]
    8 ?        SW<    0:00 [kblockd/0]
    9 ?        SW<    0:01 [kblockd/1]
   10 ?        SW     0:00 [khubd]
   11 ?        SW     0:00 [kirqd]
   12 ?        SW     0:00 [pdflush]
   13 ?        SW     0:07 [pdflush]
   14 ?        SW     0:17 [kswapd0]
   15 ?        SW<    0:00 [aio/0]
   16 ?        SW<    0:00 [aio/1]
   17 ?        SW     0:00 [scsi_eh_0]
   18 ?        SW     0:00 [ahc_dv_0]
   19 ?        SW     0:00 [kseriod]
  142 ?        SW     0:01 [kjournald]
  143 ?        SW     0:00 [kjournald]
  144 ?        SW     0:05 [kjournald]

Kernel threads are not that expensive, but they do take up some kernel memory and clutter up ps listings. Imagine what the listing would look like on a system with a large number of processors. More to the point, many of these threads are likely to be unnecessary, and that bugs kernel hackers.

As a result, there will probably be a rework of the workqueue mechanism at some point, when somebody feels motivated to do it. One possible change would be to turn the default workqueue into a thread pool of sorts; if no thread is available when schedule_work() is called, a new one is created to handle the task. Some sort of timeout mechanism would trim the threads down when the load drops. It has also been noted that many users of workqueues don't really need a thread for every processor; a single thread would be adequate for the job. An interface change allowing the creator to specify whether per-CPU threads are needed could cut down on the number of threads considerably.

Implementing changes of this nature would not be particularly difficult. Whether a rework of something as fundamental is the workqueue interface is appropriate at this stage of development is another question, however.

to post comments

Too many threads?

Posted Aug 15, 2003 1:11 UTC (Fri) by giraffedata (guest, #1954) [Link] (1 responses)

I've had a lot of discussions about the cost of threads, and I've come to the conclusion that the main cost is the line in the ps display. And the consequent mind space it takes up for those that try to comprehend all the processes in the system. On other systems where threads are organized into a hierarchy and a thousand threads take up one line of ps, people are much more comfortable with 1000 threads.

It seems ridiculous to redesign anything just to save lines in a ps display. There must be some easy way to clean up the ps display so we can use the power of threads without feeling like they're costing us too much.

Too many threads?

Posted Aug 15, 2003 15:08 UTC (Fri) by pimlott (guest, #1535) [Link]

I've had a lot of discussions about the cost of threads, and I've come to the conclusion that the main cost is the line in the ps display.

You're joking, I hope! But you're right that this, like kernel tasks, is best handled in ps. Except the kernel needs to export the necessary information. For kernel tasks, perhaps there could be a "kernel-internal" flag. For combining threads of the same "process", it is less clear what the criterion should be, since Linux gives you so many ways to create related tasks. There are also lots of multi-forking programs that really should be combined in ps. Here's an idea: processes with a common ancestry that have not "exec"ed since they branched are combined by ps. The information to do that may already be available.