Am Donnerstag, 7. Oktober 2004 18:32 schrieb Feyd:
> Oliver Neukum wrote:
> > Am Donnerstag, 7. Oktober 2004 16:26 schrieb Duncan Sands:
> >
> >>>And would be quite wrong. The 2.6 code allows users to trigger
> >>>an allocation of 32K in kernel space. The impact on the VM can be
> >>>dreadful. If anything you should port Manuel's code to 2.6.
> >>
> >>Don't you mean 16k? Also, did you really see a bad effect in practice?
> >>If so, proc_submiturb should be changed as well.
> >
> >
> > 1. kmalloc records the size of the allocation. At a limit of exactly 16384,
> > it cannot fit into 16K
> > 2. My new camera fortunately uses storage :-)
> > However reports of 16K failures with networking are common
> > 3. Yes, it should.
>
> Are the usb controllers s/g capable? If so, the usb_buffer_alloc could
> use vmalloc for high order allocations.
If you use vmalloc you need to introduce an arbitrary limit on the transfer
size. If you don't, you are allowing unlimited allocations from a space that is not
very large in the first place.
An iterative approach doesn't have that drawback. A dual urb technology
would be even better, but if you care that much about performance you
should write a kernel driver.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
