On Fri, 28 Aug 2009, Rafael J. Wysocki wrote: > > Given this design, why bother to invoke device_resume() for the async > > devices? Why not just start up a bunch of async threads, each of which > > calls async_resume() repeatedly until everything is finished? (And > > rearrange async_resume() to scan the list first and do the actual > > resume second.) > > > > The same goes for the noirq versions. > > I thought about that, but there are a few things to figure out: > - how many threads to start That's a tough question. Right now you start roughly as many threads as there are async devices. That seems like overkill. I would expect that a reasonably small number of threads would suffice to achieve most of the possible time savings. Something on the order of 10 should work well. If the majority of the time is spent handling N devices then N+1 threads would be enough. Judging from some of the comments posted earlier, even 4 threads would give a big advantage. > - when to start them You might as well start them at the beginning of dpm_resume and dpm_resume_noirq. That way they can overlap with the synchronous operations. > - stop condition When an error occurs or when op_started has been set for every remaining async device. > I had a few ideas, but then I thought it would be simpler to start an async > thread when we know there's some async work to do (ie. there's an async > device to handle) and make each async thread browse the list just once (the > rationale is that we've just handled a device, so there's a chance there are > some devices with satisfied dependencies down the list). It comes down to this: Should there be many threads, each of which browses the list only once, or should there be a few threads, each of which browses the list many times? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
