Re: Runtime PM workqueue killing system performance with USB

2014-05-23 Thread Will Deacon
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

Re: Runtime PM workqueue killing system performance with USB

2014-05-23 Thread Will Deacon
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

Re: Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Alan Stern
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

Re: Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Will Deacon
Hi Alan, On Thu, May 22, 2014 at 04:02:06PM +0100, Alan Stern wrote: > On Thu, 22 May 2014, Will Deacon wrote: > > Consequently, I see a kworker thread on each CPU consuming a significant > > amount of the system resources. Worse, if I enable something like kmemleak > > (which adds more work to

Re: Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, Will Deacon wrote: > Hi all, > > Although I don't think this is a new issue, booting mainline on my vexpress > a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each > CPU being constantly 20-50% loaded. A bit of investigation shows that this > is due to

Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Will Deacon
Hi all, Although I don't think this is a new issue, booting mainline on my vexpress a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each CPU being constantly 20-50% loaded. A bit of investigation shows that this is due to the runtime-pm callbacks trying to autosuspend USB,

Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Will Deacon
Hi all, Although I don't think this is a new issue, booting mainline on my vexpress a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each CPU being constantly 20-50% loaded. A bit of investigation shows that this is due to the runtime-pm callbacks trying to autosuspend USB,

Re: Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Alan Stern
On Thu, 22 May 2014, Will Deacon wrote: Hi all, Although I don't think this is a new issue, booting mainline on my vexpress a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each CPU being constantly 20-50% loaded. A bit of investigation shows that this is due to the

Re: Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Will Deacon
Hi Alan, On Thu, May 22, 2014 at 04:02:06PM +0100, Alan Stern wrote: On Thu, 22 May 2014, Will Deacon wrote: Consequently, I see a kworker thread on each CPU consuming a significant amount of the system resources. Worse, if I enable something like kmemleak (which adds more work to the

Re: Runtime PM workqueue killing system performance with USB

2014-05-22 Thread Alan Stern
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