Re: [PATCH 34/35] async: use workqueue for worker pool
From: Arjan van de Ven
Date: Tue Jun 29 2010 - 14:41:28 EST
On 6/29/2010 11:34 AM, Tejun Heo wrote:
On 06/29/2010 08:22 PM, Arjan van de Ven wrote:
I'm not trying to suggest "unbound". I'm trying to suggest "don'tWell, the thing is, for most cases, binding to cpus is simply better.
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.
depends on the user.
For "throw over the wall" work, this is unclear.
Especially in the light of hyperthreading (sharing L1 cache) or even
modern cpus (where many cores share a fast L3 cache).
I'm fine with a solution that has the caller say 'run anywhere' vs 'try
to run local'.
I suspect there will be many many cases of 'run anywhere'.isn't hard at
all. I just wanna know whether it's something which is
actually useful. So, where would that be useful?
I think it's useful for all users of your worker pool, not (just) async.
it's a severe limitation of the current linux infrastructure, and your
infrastructure has the chance to fix this...
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/