Menu
▾
▴
Re: [libusb] libusb task utilization
|
From: Doak, R. (GE Healthcare) <Rog...@me...> - 2013-06-28 19:57:22
|
Hans Sorry for the delay I ran the test you requested on my linux PC (has an I7 processor, changed the name of the test executable to lTestUsb): All 8 USB devices sending 506 bytes at 120Hz running on my linux PC only takes about 6% (Alex indicated the multiple cores is why idle is at 99.7% so an application could possibly take 800%, he did not know why the PPD top would not match between the idle time and task percentage since it's a single core): top - 12:04:41 up 1 day, 1:11, 1 user, load average: 0.15, 0.11, 0.06 Tasks: 270 total, 1 running, 268 sleeping, 0 stopped, 1 zombie Cpu(s): 0.2%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 15981328k total, 3359904k used, 12621424k free, 294984k buffers Swap: 15625212k total, 0k used, 15625212k free, 1894464k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17401 root RT 0 11576 796 660 S 6 0.0 0:11.61 lTestUsb We tried turning on CONFIG_USB_EHCI_TT_NEWSCHED in version 2.6 cross compiled for the IMX535 but that didn't help (same 100% utilization with only 4 devices): Linux 192.168.252.99 2.6.35.3.rev3 #1 PREEMPT Fri Jun 28 12:30:21 CDT 2013 armv7l GNU/Linux zcat /proc/config.gz | grep TT CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y top - 23:25:38 up 6 min, 2 users, load average: 2.46, 0.76, 0.28 Tasks: 55 total, 3 running, 52 sleeping, 0 stopped, 0 zombie Cpu(s): 1.0%us, 95.1%sy, 0.0%ni, 3.3%id, 0.3%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 511392k total, 41956k used, 469436k free, 0k buffers Swap: 0k total, 0k used, 0k free, 12716k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1490 root RT 0 10408 780 652 R 94.7 0.2 0:21.09 testUsb We even tried version 3.1 (since we have to crosscompile so its not easy for us to try new versions) but that didn't help either: Linux 192.168.252.99 3.1.1+ #127 PREEMPT Fri Feb 8 09:33:41 PST 2013 armv7l GNU/Linux zcat /proc/config.gz | grep TT CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y top - 23:35:56 up 4 min, 2 users, load average: 2.44, 0.60, 0.21 Tasks: 48 total, 5 running, 43 sleeping, 0 stopped, 0 zombie Cpu(s): 2.0%us, 98.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 441348k total, 22140k used, 419208k free, 0k buffers Swap: 0k total, 0k used, 0k free, 8916k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 994 root RT 0 10412 780 652 R 99.9 0.2 0:22.07 testUsb I can remove two of the 4 devices and the CPU utilization returns to normal: Removing 2 USB devices after CPU is at 100% with 4 causes the CPU load to return to normal with testUsb only utilizing between 1.6% and 5% of the CPU. So I don't understand why CPU utilization pegs on the IMX535 with only 4 devices? Roger -----Original Message----- From: Hans de Goede [mailto:hde...@re...] Sent: Thursday, June 27, 2013 8:29 AM To: Doak, Roger (GE Healthcare) Cc: lib...@li... Subject: Re: [libusb] libusb task utilization Hi, On 06/27/2013 02:48 PM, Doak, Roger (GE Healthcare) wrote: > Hans > We are using the controller 2 on the IMX535 Freescale chip which should be full featured. Also the I believe the kernel thread would have indicated high utilization if it were the driver: > Mem: 45408K used, 466276K free, 0K shrd, 0K buff, 29740K cached > CPU: 0.7% usr 97.2% sys 0.0% nic 1.9% idle 0.0% io 0.0% irq 0.0% > sirq Notice 97.2% sys, so it is the driver taking all the time, not libusb (which is taking some part of the 0.7% usr). But indeed the mx53 does seem to has an ehci controller. So I guess the regular ehci-sched.c code is having trouble scheduling the large (ish) amounts of transfers you're submitting. It would still be interesting to run the same tests on a pc, to see if this causes a significant (or at least measurable load there too. Regards, Hans > Load average: 3.33 3.91 2.63 4/52 1819 > PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND > 1810 1350 root R 10404 2.0 0 94.0 ./testUsb > 1089 2 root SW 0 0.0 0 1.3 [w1_bus_master1] > 1261 1 root S 2464 0.4 0 0.9 klogd > 1345 1 root R 2464 0.4 0 0.4 klogd > 1343 1 root S 2464 0.4 0 0.4 syslogd -S -m 0 -b 2 -l 8 -s 10000 > 1752 1749 root R 2828 0.5 0 0.2 top -d5 > 1258 1 root S 2464 0.4 0 0.2 syslogd -S -m 0 -b 10 -l 5 > 264 2 root SW 0 0.0 0 0.2 [rpciod/0] > 1747 1337 root S 7032 1.3 0 0.0 sshd: root@pts/0 > 1337 1 root S 4472 0.8 0 0.0 /usr/sbin/sshd > 1350 1 root S 2828 0.5 0 0.0 -sh > 1749 1747 root S 2828 0.5 0 0.0 -sh > 1347 1 root S 2468 0.4 0 0.0 /sbin/getty -L tty0 115200 vt100 > 1231 1 root S < 1956 0.3 0 0.0 /sbin/udevd --daemon > 1 0 root S 1892 0.3 0 0.0 init [5] > 5 2 root SW 0 0.0 0 0.0 [events/0] > 215 2 root SW 0 0.0 0 0.0 [khubd] > 186 2 root SW 0 0.0 0 0.0 [sync_supers] > 188 2 root SW 0 0.0 0 0.0 [bdi-default] > 242 2 root SW 0 0.0 0 0.0 [kmmcd] > 345 2 root SW 0 0.0 0 0.0 [nfsiod] > 6 2 root SW 0 0.0 0 0.0 [khelper] > 3 2 root SW 0 0.0 0 0.0 [ksoftirqd/0] > 2 0 root SW 0 0.0 0 0.0 [kthreadd] > 4 2 root SW 0 0.0 0 0.0 [watchdog/0] > 9 2 root SW 0 0.0 0 0.0 [async/mgr] > 10 2 root SW 0 0.0 0 0.0 [pm] > 84 2 root SW 0 0.0 0 0.0 [usb_wakeup thre] > 85 2 root SW 0 0.0 0 0.0 [usb_wakeup thre] > 86 2 root SW 0 0.0 0 0.0 [usb_wakeup thre] > 190 2 root SW 0 0.0 0 0.0 [kblockd/0] > 200 2 root SW 0 0.0 0 0.0 [mxc_spi.0] > 203 2 root SW 0 0.0 0 0.0 [mxc_spi.1] > 209 2 root SW 0 0.0 0 0.0 [otg_switch/0] > 218 2 root SW 0 0.0 0 0.0 [kseriod] > 284 2 root SW 0 0.0 0 0.0 [khungtaskd] > 285 2 root SW 0 0.0 0 0.0 [kswapd0] > 333 2 root SW 0 0.0 0 0.0 [aio/0] > 353 2 root SW 0 0.0 0 0.0 [crypto/0] > 968 2 root SW 0 0.0 0 0.0 [kapmd] > 1059 2 root SW 0 0.0 0 0.0 [irq/292-atmel_m] > 1100 2 root SW 0 0.0 0 0.0 [kondemand/0] > 1101 2 root SW 0 0.0 0 0.0 [kconservative/0] > 1104 2 root SW 0 0.0 0 0.0 [vpu_wq/0] > 1113 2 root SW 0 0.0 0 0.0 [esdhc_wq/0] > 1116 2 root SW 0 0.0 0 0.0 [esdhc_wq/0] > 1118 2 root SW 0 0.0 0 0.0 [esdhc_wq/0] > 1127 2 root SW 0 0.0 0 0.0 [usbhid_resumer] > 1134 2 root SW 0 0.0 0 0.0 [mmcqd] > 1178 2 root SW 0 0.0 0 0.0 [mmcqd] > 1785 2 root SW 0 0.0 0 0.0 [flush-0:13] > To isolate the failure I developed an application that strictly communicates with the 4 external USB devices (attached). As you can see above the application utilization is pegged. Oddly immediately re-submitting the transfer (see dumpTransfer function) seems to make the problem worse not better? > Roger > -----Original Message----- > From: Hans de Goede [mailto:hde...@re...] > Sent: Wednesday, June 26, 2013 10:05 AM > To: Doak, Roger (GE Healthcare) > Cc: lib...@li...<mailto:lib...@li...> > Subject: Re: [libusb] libusb task utilization Hi, On 06/26/2013 04:23 > PM, Doak, Roger (GE Healthcare) wrote: >> Libusb developers, >> >> We are using Libusb 1.0.9 on a Linux platform. Our host is using >> Asynchronous device I/O and interrupt transfer. We have a dedicated >> high priority task that calls libusb handle events. When a device is >> connected eight 64 byte buffers are submitted to ensure the library >> always has a buffer to write incoming data into. The host can have >> up to 8 USB devices connected. We wanted to ensure we had enough CPU >> to handle all 8 simultaneously so we programed the USB devices to >> send 506 bytes at 120Hz (these will be segmented into seven 64 byte >> packets and one 58 byte packet). For the first two devices connected >> the libusb task only used an additional 2% CPU each. However the >> utilization jumped when the 3^rd device was connected to 30% but then >> settled back down. When the 4^th device was connected the >> utilization pegged at near 100% and stayed there. To ensure the >> utilization was strictly due to the > libusb library the data is being dumped and the transfer buffer immediately resubmitted but that didn't help. Decreasing the transfer rate to 60Hz allowed the 4 devices to work but what is causing libusb to consume so much CPU? > I think the answer to that probably is the kernel hcd driver, as you submit more packets scheduling (managing the usb bandwidth) becomes more complicated. > Also if your Linux platform is a non intel embedded system, your hcd > may be of "varying" quality. In general there are 2 types of hcd-s in > embedded > chips: 1) ohci/uhci/ehci, these are fine 2) other "creative" designs, often otg capabe, these suck. > If you are indeed on a non Intel platform, it would be good to try and reproduce things on an intel machine. Since that is more powerfull hardware, you will likely see less cpu usage but you should also see a more linear growth of the usage as you add devices. > If you have multiple usb busses it will likely help greatly if you try to plug the devices into ports which belong to different busses. > Regards, > Hans |
