linux-kernel - high cpu load on omap3 using musb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Jan 2014 08:44:57 -0800
From:	Adam Wozniak <awozniak@...bot.com>
To:	<linux-kernel@...r.kernel.org>, <linux-arm@...ts.infradead.org>,
	<linux-usb@...r.kernel.org>, "Agius, Frank" <fagius@...bot.com>
Subject: high cpu load on omap3 using musb

With a USB 2.0 webcam attached to the OTG port on an OMAP3 (applies to 
overo gumstix, beagleboard, probably others) we see a high CPU load in a 
kworker thread.

Between 2.6.33 and 2.6.34 musb_core.c changed.

IRQ handlers changed with the result that a worker in musb_core.c got 
scheduled far more frequently than needed.

I've included a patch below against 3.7, but i think it'll apply against 
mainline.
[I apologize for any whitespace mangling.  I've also attached the patch.]

I'd like more eyeballs to tell me if this is right.  I'd also like to 
know who I need to talk to to get this pushed into mainline.

--Adam

# The MUSB IRQ schedules work on every interrupt.
# This is unnecessary, and causes excessive CPU load.
#
# Here we only schedule work if there is something for
# the worker to do.

Index: git/drivers/usb/musb/musb_core.c
===================================================================
--- git.orig/drivers/usb/musb/musb_core.c
+++ git/drivers/usb/musb/musb_core.c
@@ -925,7 +925,9 @@ b_host:
         }
  #endif

-       schedule_work(&musb->irq_work);
+       if (musb->xceiv->state != musb->xceiv_old_state) {
+               schedule_work(&musb->irq_work);
+       }

         return handled;
  }

View attachment "musb_smartwork.patch" of type "text/x-patch" (561 bytes)