| |||||||||||||
Working on workqueuesWorking on workqueuesPosted Sep 9, 2010 16:27 UTC (Thu) by marcH (subscriber, #57642)Parent article: Working on workqueues
> After that, there is no end of special-purpose kernel threads elsewhere in the system. Not all of them will be amenable to conversion to workqueues, but quite a few of them should be. Over time, that should translate to less system resource use, cleaner "ps" output, and a better-running system.
Naive question: isn't this change going to make more difficult to see what kernel threads are busy doing?
(Log in to post comments)
Working on workqueues Posted Sep 9, 2010 16:34 UTC (Thu) by nix (subscriber, #2304) [Link]
That's a tolerable cost, I'd say. Right now, my quad-core hyperthreaded Nehalem (not *that* beefy a machine) creates nearly a thousand kernel threads at startup (e.g. one direct-IO thread per ext4 filesystem per CPU!). That's way past ridiculous. Anything that fixes it is a good thing.
Working on workqueues Posted Sep 11, 2010 1:31 UTC (Sat) by dmag (subscriber, #17775) [Link]
> isn't this change going to make more difficult to see what kernel threads are busy doing?
Yes, but you only got to see those threads that were spun off as dedicated threads. It's a case of "just because it's easy to measure doesn't mean it's the whole picture."
Working on workqueues Posted Sep 17, 2010 5:59 UTC (Fri) by kevinm (guest, #69913) [Link]
Perhaps the kernel thread's comm can be (optionally) changed to include the name of the workqueue it's currently running work for? Similar to the way init's comm tells you what runlevel it's in.
|
|||||||||||||