Re: workqueue thing

From: Arjan van de Ven
Date: Mon Dec 21 2009 - 06:17:17 EST

On 12/21/2009 12:09, Andi Kleen wrote:
On Mon, Dec 21, 2009 at 10:17:54AM +0100, Jens Axboe wrote:
On Fri, Dec 18 2009, Arjan van de Ven wrote:
in addition, threads are cheap. Linux has no technical problem with
running 100's of kernel threads (if not 1000s); they cost basically a
task struct and a stack (2 pages) each and that's about it. making an
elaborate-and-thus-fragile design to save a few kernel threads is
likely a bad design direction...

One would hope not, since that is by no means outside of what you see on
boxes today... Thousands. The fact that they are cheap, is not an
argument against doing it right. Conceptually, I think the concurrency
managed work queue pool is a much cleaner (and efficient) design.

Agreed. Even if possible thousands of threads waste precious cache.

only used ones waste cache ;-)

And they look ugly in ps.

that we could solve by making them properly threads of each other; ps and co
already (at least by default) fold threads of the same program into one.

Also the nice thing about dynamically sizing the thread pool
is that if something bad (error condition that takes long) happens
in one work queue for a specific subsystem there's still a chance
to make process with other operations in the same subsystem.

same is true for hitting some form of contention; just make an extra thread
so that the rest can continue.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at