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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Feb 2009 03:24:15 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [RFC][PATCH] create workqueue threads only when needed

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.
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/