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:
On 06/29/2010 08:07 PM, Arjan van de Ven wrote:
we might be talking past eachother. ;-)That's the main point to discuss tho. If you exaggerate the use case
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)
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
I'm not trying to suggest "unbound".
I'm trying to suggest "don't start bounding until you hit # threads >= #
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/