[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200817152507.GC112820@rowland.harvard.edu>
Date: Mon, 17 Aug 2020 11:25:07 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Jim Baxter <jim_baxter@...tor.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-usb@...r.kernel.org,
"Resch Carsten \(CM/ESO6\)" <Carsten.Resch@...bosch.com>,
"Rosca, Eugeniu \(ADITG/ESB\)" <erosca@...adit-jv.com>
Subject: Re: PROBLEM: Long Workqueue delays.
On Mon, Aug 17, 2020 at 12:40:03PM +0100, Jim Baxter wrote:
> We have issues with the workqueue of the kernel overloading the CPU 0
> when we we disconnect a USB stick.
Do you unmount the stick before disconnecting it?
> This results in other items on the shared workqueue being delayed by
> around 6.5 seconds with a default kernel configuration and 2.3 seconds
> on a config tailored for our RCar embedded platform.
>
> I am aware there will be delays on the shared workqueue, are the delays
> we are seeing considered normal?
Assuming the workqueue delay is caused by the USB subsystem, you may be
able to get more information by turning on USB dynamic debugging:
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
and seeing what shows up in the dmesg log.
One long-running job should not normally be enough to delay an entire
workqueues. Workqueues are allowed to spawn multiple threads; they are
supposed to resize themselves dynamically as required.
Alan Stern
Powered by blists - more mailing lists