On Thu, Aug 18, 2011 at 09:13:04PM +0200, Markus Rechberger wrote: > On Thu, Aug 18, 2011 at 8:37 PM, Greg KH <gregkh@xxxxxxx> wrote: > > On Wed, Aug 17, 2011 at 07:07:01PM +0200, Markus Rechberger wrote: > >> Hi, > >> > >> this patch increases the maximum buffersize for bulk transfers, our > >> devices support at least up to 46k bytes for bulk transfers. > >> This patch allows us to lower the iterations between kernel and > >> userspace and lower the system pressure. > > > > But as Oliver pointed out, this increases the memory pressure. I'm > > curious why you say there is "system pressure" with the current buffer > > size. What is the problems here, you are just passing the same logic > > issues down to the kernel, that you should be handling in userspace if > > you want to use usbfs. > > > > userspace applications are not realtime applications, the bigger the buffer > the less buffers will be required. In userspace, yes, but it's not "free", you still end up allocating the same amount of memory in the kernel instead. And larger memory allocations like this, provide more memory pressure on the system overall, which can cause problems. > As noted this is just 1/4th the buffersize we are already using with > Isochronous. Back then with small isochronous buffers even moving the > mozilla GUI window could cause incomplete data (and I'm talking about > 170mbit per second transfers here), with increased buffers this issue > is gone (and it's gone since I submitted a similar patch for > isochronous ~1-2 years ago). In case of bulk allocations can go down > for 2/3 of the current pressure, of course it goes up on another side > but that side has a better performance. Do you have real numbers and example programs that show the difference of this kernel change making a real difference? > >> Signed-off-by: Markus Rechberger <mrechberger@xxxxxxxxx> > > > > Also note that this is a user/kernel API that you are changing, are you > > _sure_ you didn't just break some user code with this change that was > > assuming that the buffer size was 16Kb, as it's been that way for the > > past 10 years? > > > > just the check about the maximum allowed buffer size will be > increased, nothing else. > Existing applications will still go for 16k. Yes, but you just changed the value the kernel can accept, which could cause problems. greg k-h -- 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
