Re: [PATCH 34/35] async: use workqueue for worker pool

From: Arjan van de Ven
Date: Tue Jun 29 2010 - 14:22:18 EST

On 6/29/2010 11:15 AM, Tejun Heo wrote:
Hello, Arjan.

On 06/29/2010 08:07 PM, Arjan van de Ven wrote:
we might be talking past eachother. ;-)

let me define an example that is simple so that we can get on the same page

assume a system with "enough" cpus, say 32.
lets say we have 2 async tasks, that each do an mdelay(1000); (yes I
know stupid, but exagerating things makes things easier to talk about)
That's the main point to discuss tho. If you exaggerate the use case
out of proportion, you'll end up with something which in the end is
useful only in the imagination and we'll be doing things just because
we can. Creating full number of unbound threads might look like a
good idea to extract maximum cpu parallelism if you exaggerate the use
case like the above but with the current actual use case, it's not
gonna buy us anything and might even cost us more via unnecessary
thread creations.

I'm not trying to suggest "unbound".
I'm trying to suggest "don't start bounding until you hit # threads >= # cpus
you have some clever tricks to deal with bounding things; but lets make sure that the simple case
of having less work to run in parallel than the number of cpus gets dealt with simple and unbound.
You also consolidate the thread pools so that you have one global pool, so unlike the current situation
where you get O(Nr pools * Nr cpus), you only get O(Nr cpus) number of threads... that's not too burdensome imo.
If you want to go below that then I think you're going too far in reducing the number of threads in your pool. Really.

so... back to my question; will those two tasks run in parallel or sequential ?

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