Mass Storage Gadget Kthread

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

 



Hi Alan,

here's a question which I hope you can help me understand :-)

Why do we have that kthread for the mass storage gadgets ? I noticed a very
interesting behavior.

Basically, the MSC class works in a loop like so:

CBW
Data Transfer
CSW

In our implemention, what we do is:

CBW
wake_up_process()
Data Transfer
wake_up_process()
CSW
wake_up_process()

Now here's the interesting bit. Every time we wake_up_process(), we basically
don't do anything until MSC's kthread gets finally scheduled and has a chance of
doing its job. This means that the host keeps sending us tokens but the UDC
doesn't have any request queued to start a transfer. This happens specially with
IN endpoints, not so much on OUT directions. See figure one [1] we can see that
host issues over 7 POLLs before UDC has finally started a usb_request, sometimes
this goes for even longer (see image [3]).

On figure two we can see that on this particular session, I had as much as 15%
of the bandwidth wasted on POLLs. With this current setup I'm 34MB/sec and with
the added 15% that would get really close to 40MB/sec.

So the question is, why do we have to wait for that kthread to get scheduled ?
Why couldn't we skip it completely ? Is there really anything left in there that
couldn't be done from within usb_request->complete() itself ?

I'll spend some time on that today and really dig that thing up, but if you know
the answer off the top of your head, I'd be happy to hear.

Thanks

[1] http://imgur.com/RHJ5jxj
[2] http://imgur.com/F9qA7j5
[3] http://imgur.com/LoaFunZ

-- 
balbi

Attachment: signature.asc
Description: PGP signature


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

  Powered by Linux