qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 18/18] usb: add ehci adapter


From: David Ahern
Subject: Re: [Qemu-devel] [PATCH 18/18] usb: add ehci adapter
Date: Tue, 17 May 2011 11:05:10 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110421 Fedora/3.1.9-2.fc14 Thunderbird/3.1.9


On 05/17/11 09:02, Gerd Hoffmann wrote:
> 
>   Hi,
> 
>> (And by the way, where are the focused patches for each, especially the
>> last one - nuking the 8kHz code?
> 
> It's squashed in, like everything else.
> 
>> We know that it worked on linux and
>> that printers, scanners and storage devices worked ok (mostly).
> 
> 8 kHz is insane.
> 
> I looked closely while trying to make 8 kHz a runtime option instead of
> a compile time option, then decided to drop it altogether as it is
> totally pointless.  qemu simply can't handle that wakeup rate.  It maxed
> out at ~3 kHz wakeups in my tests.  And it burns tons of CPU time.

Our mileage varies. While CPU usage was high (30%'ish) when the device
was in use, the controller was stopped when devices are not accessed.
All in all my laptop was billowing smoke while using it.

> 
> I also don't see what it would buy us.  We can wakeup with 1 kHz rate
> (maybe even lower), then emulate 8 (or more) microframes each time.

How much time have you spent looking at isochronous devices (web cams,
audio streaming, iphones)? Your positive that the 8k code will not be
needed for it? My point is that you prematurely nuked code that is
controlled by a define which allows you to try both paths.

David

> 
> Throughput issues (guess this is the reason to try 8kHz wakeups) need to
> be addressed by modeling data pipes in the usb system instead of playing
> ping-pong between EHCI and USB device emulation for each single usb
> packet, at 8 kHz.


> 
> I see the ehci merge just as very first step.  USB 2.0 (and 3.0) support
> in qemu still has a loooooooong way to go.
> 
> cheers,
>   Gerd
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]