Re: [PATCH] Memory mapping for USBFS

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

 



On Sat, Sep 28, 2013 at 8:52 PM, Markus Rechberger
<mrechberger@xxxxxxxxx> wrote:
> On Sat, Sep 28, 2013 at 8:28 PM, Markus Rechberger
> <mrechberger@xxxxxxxxx> wrote:
>> On Sat, Sep 28, 2013 at 7:43 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>>> On Sat, 28 Sep 2013, Markus Rechberger wrote:
>>>
>>>> >> My next step would be to eliminate the kmallocs/kfrees for the single
>>>> >> urbs (just by allocating the urbs with the same mechanism and passing
>>>> >> the returned pointer to SUBMIT_URB).
>>>> >
>>>> > The time spent allocating and freeing URBs is probably pretty small.
>>>> >
>>>>
>>>> pre-allocating should at least solve those issues:
>>>> http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780
>>>
>>> As far as I can tell, that bug report isn't related to URB allocation.
>>> It looks like the failure occurred when allocating memory for the
>>> transfer buffer, not when allocating memory for the URB.
>>
>> That's what I mean, URB pre-allocation would just be for having it
>> complete (the same is available on MacOSX), if it's not wanted I don't
>> mind either.
>> At the time the bugreport was made in our forum we were allocating
>> around 15k buffers, it happened during runtime so it worked for some
>> time and then stopped with those allocation problems.
>>
>> I hope the SG transfer does not introduce any latency issues we have
>> some usb chipsets which are very picky about latency issues on
>> embedded systems.
>> We got it work by tuning the transfer size, if the timings are not met
>> the device will just disable the transfer.
>> Unfortunately it will take a second to detect that by the driver and
>> re-enabling the transfer which means that it will corrupt the data.
>> I do not have a good feeling about pushing SG transfers into the
>> kernel by modifying the legacy mode without having any experience with
>> it. While the idea behind SG transfers is definitely ok but who knows
>> how it will perform with such devices.
>>
>
> I put together a few reports:
> http://support.sundtek.com/index.php/topic,350.0.html
> http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780
> http://support.sundtek.com/index.php/topic,411.msg2153.html#msg2153
> http://support.sundtek.com/index.php/topic,531.msg2956.html#msg2956
> http://support.sundtek.com/index.php/topic,364.msg1829.html#msg1829
>

to follow up I know why it doesn't happen anymore because customers
are using a kernel module which does optimized transfers and
pre-allocated the URBs and transfer buffer in kernelspace, the
interface just copies the datastream to our actual driver which sits
in userspace.
Goal is to get rid of that kernel module which is working around that
allocation bug.

Allan, Greg, can we add another IOCTL for telling USBFS to not use SG
transfers (it also allocates 15k buffers and will lead to the same
problem)?
The old behavior was already broke, the SG transfers won't improve the
situation in that case either.

Those Sheevaplugs have 128mb memory, regular routers and NAS systems
don't necessarily have more either.

> they are all about page allocation failure when submitting the URB
> packet (I agree that it's probably mostly about the 15-16k allocation
> problem here).
>
> They only came up a few times between 2010 - (late) 2012 (we were also
> able to reproduce this on our Sheevaplug occasionally since we do
> stronger testing with it I guess). Not sure if that problem still
> happens, at least it didn't pop up in our forum this year.
>
> Markus
>
>>>> but now when looking closer SG support can disable the support for
>>>> shared memory support for bulk transfers.
>>>
>>> I don't know what you're talking about.  What has shared memory got to
>>> do with SG or anything else we are discussing?
>>>
>>
>> sorry I probably picked the wrong words for that.
>>
>>>> It should be possible to turn off SG Support in favor of
>>>> pre-allocating the buffers (or preallocate the buffers for SG).
>>>
>>> Only if the buffer can be allocated as a single contiguous region of
>>> memory, in which case SG wouldn't be needed anyway.
>>>
>>>> This problem happened several times on Sheevaplug ARM systems from Marvell.
>>>
>>> I don't see what difference the platform or architecture would make.
>>>
>>> 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




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

  Powered by Linux