Re: uhci vs ehci: 5 wakeups/s saved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Wed, 3 Oct 2007, Sarah Sharp wrote:

> On Wed, Oct 03, 2007 at 02:29:49PM +0100, Alan Jenkins wrote:
> > My internet arrives via a USB 2.0 wireless adaptor.
> > Using UHCI instead of EHCI saves ~5 wakeup/s:
> > 
> > With ehci_hcd loaded (and not uhci_hcd):
> >   31.1% ( 10.0)     <kernel core> : ehci_work (ehci_watchdog)
> >   30.4% (  9.8)       <interrupt> : ehci_hcd:usb5

Pardon me, but can somebody explain what those numbers mean?  Are they 
an average number of interrupts per second?

> > With uhci_hcd loaded (and not ehci_hcd):
> >   48.0% (  9.8)       <interrupt> : uhci_hcd:usb1
> >   19.6% (  4.0)   <kernel module> : usb_hcd_poll_rh_status (rh_timer_func)
> > 
> > Since ehci_hcd also disagrees with my MP3 player, I'm not sure I want 
> > USB 2.0 any more ;-).  I may end up blacklisting the module.

Nobody is forcing you to use it.  :-)  Feel free to blacklist it if you
can get better performance without it.

> How does it "disagree" with your MP3 player?
> > I was suprised, since I've read[1] and seem to remember verifying that 
> > UHCI causes a constant 1000 wakeups/s, and that this was unavoidable 
> > given the UHCI specification.

The blogger in [1] is completely wrong.  UHCI does not cause a constant
1000 interrupts per second.

> >  I'm running a 2.6.23-rc9-hrt1 kernel 
> > (-rc8-hrt1 patch applied cleanly to -rc9).
> > 
> > Is this expected?

It's hard to be precise.  Here's a partial analysis:

The interrupts for each driver fall into two categories.  With uhci-hcd
they are labelled in your listing as usb_hcd_poll_rh_status and
uhci_hcd; with ehci-hcd they are labelled as ehci_watchdog and

Now in general you should expect the total uhci_hcd and ehci_hcd
numbers (not necessarily the averages!) to be roughly equal.  The
uhci_hcd number might be somewhat higher.  The poll_rh_status
interrupts will occur at a steady 4/second.  The ehci_watchdog value is
harder to pin down.  Bear in mind, however, that during the time when
those interrupts arrive, the EHCI controller is performing DMA, which
will prevent the CPU from entering a deep sleep state in any case.  
(In fact, one of the purposes of the ehci_watchdog interrupt is to tell
the driver that it can turn off DMA.)

One other thing: EHCI transfers data 40 times faster than UHCI.  All
else being equal, you would be justified in expecting it to generate 40
times as many interrupts per second.  The fact that it doesn't
indicates something -- perhaps that the real bottleneck isn't in these 
controllers at all but somewhere else in the system.

> > Could it be USB autosuspend at work?  I've checked and "echo -1 > 
> > /sys/module/usbcoreparamters/autosuspend" doesn't change the number of 
> > wake-ups, but perhaps I'm missing something.
> It's unlikely that your USB wireless adaptor is being autosuspended.  I
> don't think there's any kernel support for wireless adaptors.  There is
> autosuspend support for USB to ethernet adaptors that run under the
> kaweth driver.  Without kernel support, the device won't autosuspend.


> > I notice that the number of interrupts is actually the same.   The 
> > difference is in the kernel polling routines - ehci_work vs 
> > usb_hcd_poll_rh_status.  Does ehci need to poll twice as often, or might 
> > it be possible to tune or hack the polling interval?

ehci doesn't poll at all under normal circumstances, but it does use a
timer to disable the async schedule.  As I mentioned above, uhci polls
at 4/second.

Alan Stern

This email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
To unsubscribe, use the last form field at:

[Linux USB]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Video Projectors]     [PDAs]     [Free Online Dating]     [Hacking TiVo]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]     [Big List of Linux Books]     [16.7MP]