Re: High CPU usage when video streaming on EHCI, 3.17.8 kernel with DMA enabled

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

 



Hi,

last time I checked uvc driver, it was doing memcpy of video buffer : see uvc_video_decode_data.

It your video resolution is big, this can eat lot's of cpu.

Doing a trace should help you.

Matthieu




Le Sun, 17 May 2015 10:06:11 -0400,
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> a écrit :

> On Sun, 17 May 2015, Tom Mises wrote:
> 
> > Hi,
> > 
> > I posted this on linux-uvc-devel, but was told the data transfer part
> > is handled by the USB driver.
> > 
> > I am running 3.17.8 kernel with DMA enabled on TI DM3730 (Gumstix
> > Overo Firestorm-P COM). When streaming video frames in mmap or userptr
> > mode, I am
> > seeing very high CPU usage, up to 70%. This CPU usage is reported to
> > be in software interrupts. The captured frames are NOT corrupted.
> > 
> > Interestingly, when running 3.5 kernel, with DMA enabled as well, the
> > CPU usage is 30% and it is reported to be mostly in the user space.
> > So, it guess it suggests PIO not DMA is actually used here.
> 
> EHCI always uses DMA.  It cannot use PIO.
> 
> > Neither of these results are satisfactory, I hoped DMA would take care
> > of the data transfer and the CPU resources would be available to run
> > data processing.
> > 
> > I used the video capture example from the V4L2 API documentation. This
> > behavior was tested and observed for two different cameras, one of
> > them working in isochronous mode, the other working in bulk mode.
> > 
> > Interrupts showing activity during the streaming are:
> > omap-dma-engine,
> > ehci_hcd:usb1.
> > 
> > I also ran another test with very low resolution and fps
> > settings, 160x90 5ps YUV422. In that case, on 3.5 kernel, CPU usage was
> > very low. However, on 3.17.8 kernel, it was still similar as before,
> > around 60% and all in software interrupts; it was dropping to zero
> > intermittently this time.
> > 
> > Perhaps, the problem is somewhere in the interaction between the UVC
> > driver and the DMA or USB driver. As far as I understand, the UVC
> > driver uses vmalloc(), which, again AFAIU, is not ideal for DMA
> > transfers. Is this known to work on other similar platforms?
> 
> I haven't heard complaints about the UVC driver.
> 
> > I am aware this is a somewhat vague
> > description unfortunately, but I am not sure what other detail would
> > be helpful. UVC debugging messages do not show anything unusual.
> > Beyond that, debugging these drivers on my own exceeds my expertise,
> > so I will welcome any suggestions.
> 
> You might be able to learn more from ftrace.  See the instructions in
> Documentation/trace/ftrace.txt.  The "irqsoff" tracer may be the best
> one to try.
> 
> > There is also the following error message from EDMA, I do not think it
> > is related though.
> > [    0.557342] edma-dma-engine edma-dma-engine.0: Can't allocate PaRAM
> > dummy slot
> > [    0.557434] edma-dma-engine: probe of edma-dma-engine.0 failed with error -22
> 
> It seems unlikely to be related.
> 
> Alan Stern
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux