Re: [PATCH 2/6] PM: Asynchronous resume of devices

Alan Stern
2009-08-28T19:59:27Z

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