Messages in this thread | | | Date | Tue, 29 Jun 2010 11:41:17 -0700 | From | Arjan van de Ven <> | Subject | Re: [PATCH 34/35] async: use workqueue for worker pool |
| |
On 6/29/2010 11:34 AM, Tejun Heo wrote: > Hello, > > 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'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. >> > Well, the thing is, for most cases, binding to cpus is simply better. >
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...
| |