Date: Tue, 22 Feb 2011 16:26:45 +1030 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Hans Petter Selasky <hselasky@c2i.net> Cc: jhb@freebsd.org, freebsd-usb@freebsd.org Subject: Re: libusb performance on 8.1 Message-ID: <A7D61A2D-CD57-46C1-B415-B02804F4606F@gsoft.com.au> In-Reply-To: <201102181608.15368.hselasky@c2i.net> References: <9CF6C32F-E230-446B-94FC-C57F0F02B0E4@gsoft.com.au> <0F80A010-B97C-4D05-B604-5EF4B07EF248@gsoft.com.au> <FF467587-6B4C-4F46-9B8B-C5041E4B224E@gsoft.com.au> <201102181608.15368.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19/02/2011, at 1:38, Hans Petter Selasky wrote: > Which harddisk driver are you using? ATA? Yes. > My guess would be that taskqueues() in the HDD drivers are using = swi-queues,=20 > instead of ordinary lower-priority queues. For example in sys/dev/ata = I found: >=20 > TASK_INIT(&request->task, 0, ata_completed, request); > ATA_DEBUG_RQ(request, "finish taskqueue_swi"); > taskqueue_enqueue(taskqueue_swi, &request->task); >=20 > Which should perhaps just be "taskqueue_thread" instead of = "taskqueue_swi". I'll try changing it and seeing if it improves things. > I've noticed during USB debugging that if certain non-DATA-xfer SCSI = commands=20 > take time to complete, the whole system is waiting apparently, at = least X11.=20 > This might indicate that synchronous code is being run from interrupt = context. Interesting.. Although in the dual core case I wouldn't have thought it = would be a huge deal would it? I had to give the dual core system I was using for testing back so I am = currently using a single core with a non-ACHI capable chipset. I'll try = and get access to the previous system again for some more testing. Do you have any suggestions for how I can find out exactly where it's = sleeping in libusb? Or I suppose once it's in the kernel.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A7D61A2D-CD57-46C1-B415-B02804F4606F>