Messages in this thread | | | Date | Tue, 29 Jun 2010 17:52:29 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 34/35] async: use workqueue for worker pool |
| |
On Tue, Jun 29, 2010 at 05:46:32PM +0200, Tejun Heo wrote: > Hello, > > On 06/29/2010 02:18 PM, Frederic Weisbecker wrote: > >> Yeah, well, that's kind of the whole point of cmwq. It would try to > >> minimize the number of used workers but the provided concurrency will > >> still be enough. No async probe will be stalled due to lack of > >> execution context and the timings should be about the same between the > >> original async implemetnation and cmwq based one. > > > > Right. I just don't know what is supposed to be slow on boot that > > needs to use async. Is that because reading some ports is slow or > > because we need to do something and wait for some times to get the > > result. > > It's things like ATA bus resetting and probing. They're usually > composed of short CPU activities and rather long sleeps.
Ok.
> > If there is a question of slow ports to probe, then cmwq wouldn't seem the > > right thing here, as it only forks when we go to sleep. > > I lost you here. If something during boot has to burn cpu cycles > (which it shouldn't, really), it has to burn cpu cycles and having > multiple concurent threads won't help anything.
It would on SMP.
> If something doesn't > burn cpu cycles but takes long, it gotta sleep and cmwq will start a > new thread immediately. So, can you please elaborate why cmwq would > be problematic?
No in this case it's not problematic, as far as the things that were using async have a small cpu burn and long sleep waiting, it looks like cmwq fits :)
| |