All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minas Harutyunyan <Minas.Harutyunyan-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
To: gregkh <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-usb <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org"
	<John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>,
	"linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: High CPU load produced by USB (DW2)
Date: Thu, 8 Feb 2018 08:50:19 +0000	[thread overview]
Message-ID: <410670D7E743164D87FA6160E7907A560113A67EBD@am04wembxa.internal.synopsys.com> (raw)
In-Reply-To: 20180207142749.GD29606@kroah.com

On 2/7/2018 6:28 PM, gregkh wrote:
> On Wed, Feb 07, 2018 at 10:48:57AM +0100, Mirza Krak wrote:
>> Hi.
>>
>> I initially started a thread on a different mailing list [1], and you
>> can take look there for some additional background.
>>
>> I am using a 4.14.15 stable kernel on a RK3288 SoC (FireFly RK3288
>> board) which uses the DW2 USB core. I have noticed that when
>> connecting a USB device there is unreasonable high CPU load produced
>> by the USB interrupts.
> 
> That's a normal problem with that kind of hardware.  I've seen devices
> with that type of USB core take a 30% cpu usage just when you plug a USB
> keyboard into the device.
> 
> There's not much the kernel can do about horrible hardware, sorry, go
> complain to the device manufacturer :(
> 
>> Here is one example with a MIDI keyboard connected on USB (not really
>> doing anything on it)
>>
>>     79     2 root     SW       0   0%  19% [irq/45-dwc2_hso]
>>     78     2 root     SW       0   0%  11% [irq/45-ff540000]
> 
> It doesn't matter if anything is happening on the device, USB goes and
> polls the device all the time, that's just the way that the protocol
> works.  With hardware like this, that polling is done by the kernel
> driver/CPU and does not have offload capability to the USB controller to
> handle this type of housekeeping.  Because of that, you see tons of CPU
> interrupts and a high load.
> 
> Again, not much we can do about that, sorry :(
> 
> good luck!
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=mnEzj_Q87pyYPBxV3CbMXuG55KNzxqhYf7tuz517xjg&s=eftxO7ffuUu2L87Mqwa6K8p7s1mpI__boRvzDI70HvY&e=
> 
dwc2 HW doesn't track (u)frames internally. SW forced to track (u)frames 
by unmasking SOF interrupts. This is why when any device with periodic 
EP connected to port require to unmask SOF's as result seen high CPU 
load. dwc2 SW dynamically mask/unmask SOF interrupts depend on using 
periodic EP by connected device.
There are no any polling in SW.

Lot of HW functionality delegated to dwc2 driver to reduce gate count in HW.
This "horrible" core very small and cheap.

good luck!

Minas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-02-08  8:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-07  9:48 High CPU load produced by USB (DW2) Mirza Krak
     [not found] ` <CALw8SCXuOCpndakFBRbP7FpJKOSH+nzNStkszWD4XTXVSK1zyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-07 14:27   ` gregkh
2018-02-08  8:50     ` Minas Harutyunyan [this message]
2018-02-08 11:02 ` Minas Harutyunyan
     [not found]   ` <410670D7E743164D87FA6160E7907A560113A67F86-ouFQeoKRuQ8bQ7k9MBbv4fufCSb+aD3WLzEdoUbNIic@public.gmane.org>
2018-02-08 13:06     ` Mirza Krak
2018-02-08 13:53       ` Minas Harutyunyan
     [not found]         ` <410670D7E743164D87FA6160E7907A560113A68287-ouFQeoKRuQ8bQ7k9MBbv4fufCSb+aD3WLzEdoUbNIic@public.gmane.org>
2018-02-14  8:57           ` Mirza Krak
2018-02-14 12:07             ` Minas Harutyunyan
     [not found]               ` <410670D7E743164D87FA6160E7907A560113A6B365-ouFQeoKRuQ8bQ7k9MBbv4fufCSb+aD3WLzEdoUbNIic@public.gmane.org>
2018-02-15 13:20                 ` Mirza Krak
2018-02-16  5:59                   ` Minas Harutyunyan
     [not found]                     ` <410670D7E743164D87FA6160E7907A560113A6C4CA-ouFQeoKRuQ8bQ7k9MBbv4fufCSb+aD3WLzEdoUbNIic@public.gmane.org>
2018-02-16 20:07                       ` Marek Vasut
2018-02-19  8:19                         ` Minas Harutyunyan
     [not found]                           ` <410670D7E743164D87FA6160E7907A560113A6E9E6-ouFQeoKRuQ8bQ7k9MBbv4fufCSb+aD3WLzEdoUbNIic@public.gmane.org>
2018-02-19  8:51                             ` Marek Vasut
2018-02-19 10:11                               ` Minas Harutyunyan
     [not found]                                 ` <410670D7E743164D87FA6160E7907A560113A6EB2B-ouFQeoKRuQ8bQ7k9MBbv4fufCSb+aD3WLzEdoUbNIic@public.gmane.org>
2018-02-19 17:02                                   ` Marek Vasut
2018-02-20  5:51                                     ` Minas Harutyunyan
     [not found]                                       ` <410670D7E743164D87FA6160E7907A560113A6F1B4-ouFQeoKRuQ8bQ7k9MBbv4fufCSb+aD3WLzEdoUbNIic@public.gmane.org>
2018-03-05 17:37                                         ` Marek Vasut
2018-03-06  6:45                                           ` Minas Harutyunyan
2018-03-06  8:09                                             ` Minas Harutyunyan
     [not found]                                               ` <410670D7E743164D87FA6160E7907A560113AB3F3D-ouFQeoKRuQ8bQ7k9MBbv4fufCSb+aD3WLzEdoUbNIic@public.gmane.org>
2018-03-07 22:42                                                 ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=410670D7E743164D87FA6160E7907A560113A67EBD@am04wembxa.internal.synopsys.com \
    --to=minas.harutyunyan-hkixbcoqz3hwk0htik3j/w@public.gmane.org \
    --cc=John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.