Re: Runtime PM workqueue killing system performance with USB

Will Deacon
2014-05-23T14:32:39Z

On Thu, May 22, 2014 at 07:14:40PM +0100, Alan Stern wrote:
> On Thu, 22 May 2014, Will Deacon wrote:
>
> > > Anyway, there are two possible ways of handling this. One is to avoid
> > > changing the error code to -EBUSY when the device in question is a root
> > > hub. Just let it go into a runtime-PM error state; it won't matter
> > > since the controller doesn't support runtime PM anyway. You can test
> > > this by changing the "if (status != 0)" line in usb_runtime_suspend to
> > >
> > > if (status != 0 && udev->parent)
> >
> > I'd tried something like this already, but I prefer your patch below. Plus,
> > this hack results in a failure being logged to dmesg on the initial suspend
> > attempt.
> >
> > > The other approach is to disable runtime PM for the root hub when the
> > > host controller driver doesn't have a bus_suspend or bus_resume method.
> > > This seems like a cleaner approach; the patch below implements it.
> >
> > Thanks for this! I can confirm that your patch below fixes the issue for me,
> > so:
> >
> > Reported-by: Will Deacon <will.deacon@arm.com>
> > Tested-by: Will Deacon <will.deacon@arm.com>
>
> You know, I think it might be best to make both changes. Even though
> runtime PM will be disabled by default, the user can always override
> this setting. If that happens, the suspend should fail with the proper
> error code instead of going into a loop.
>
> Do you mind if I add the change to usb_runtime_suspend() in the patch?

That sounds sensible -- if runtime PM is being forced on, then errors are
worth reporting.

Will