Re: [RFC][PATCH] create workqueue threads only when needed

[Frederic Weisbecker <fweisbec@gmail.com>]

On Mon, Feb 02, 2009 at 08:37:41AM +1100, Benjamin Herrenschmidt wrote:
> 
> > I don't know, most of those I've looked on are not documented about the reason
> > for a private workqueue. I guess most of them can use the usual kevent.
> 
> The main problem with kevent is that it gets clogged up.


I don't think so. Here is a snapshot of the workqueue tracer in my
box currently:

# CPU  INSERTED  EXECUTED   NAME
# |      |         |          |

  1      0          0       hda0/1
  1    589        589       reiserfs/1
  1      0          0       scsi_tgtd/1
  1      0          0       aio/1
  1      0          0       ata/1
  1    378        378       kblockd/1
  1      0          0       kintegrityd/1
  1      2          2       work_on_cpu/1
  1   8706       8706       events/1

  0  19994      19994       cqueue
  0      0          0       hda0/0
  0    501        501       reiserfs/0
  0      0          0       scsi_tgtd/0
  0      0          0       aio/0
  0      0          0       ata_aux
  0      0          0       ata/0
  0      4          4       kacpi_notify
  0     22         22       kacpid
  0    379        379       kblockd/0
  0      0          0       kintegrityd/0
  0   1056       1056       khelper
  0     15         15       work_on_cpu/0
  0   9367       9367       events/0
  0      0          0       cpuset

And the result of uptime:

 02:51:40 up  2:22,  6 users,  load average: 0.22, 0.34, 0.59

So I have a total of 18073 works sent and performed by kevent for
10300 seconds.

An average of a bit less than 2 works on kevents per seconds is not about something
clogged, especially since we are talking about small jobs, usually those which play
the role of bottom halves and would have fit in a tasklet/softirq by the past.

Now if you look at the other workqueues.
Most of them don't do anything (more likely I don't do anything with them).

Khelper can't be replaced since it performs slow works which may wait for userspace
processes completion although I'm not sure it's still useful after the boot.

cqueue is usually inactive but I raised a good number of events artificially on it, I
just sent a patch to create its workqueue only when needed.

And for the others, I don't know yet.

 
> That's were thread pools kick in ... tried using Dave Howells slow
> work ?


I think it can be useful, as an example the kpsmoused workqueue receive rare
and slow works of mouse resynchronisation.
I wanted to convert it into a slow work created only on the fly.

But..I don't find it. I've seen some patches about it but it doesn't seem
to be merged.
So I tried something else for kpsmoused: turn it into a thread created on the fly.

But I think these slow works could be useful for such things.


> Cheers,
> Ben.
> 
>