linux-kernel - Re: [PATCH] Increase usbfs bulk buffer size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+O4pCJn8bEafT1Z83gGY00-y705nxN6+tcr3pe6HLDW0s6sUw@mail.gmail.com>
Date:	Thu, 18 Aug 2011 21:13:04 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	Greg KH <gregkh@...e.de>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Increase usbfs bulk buffer size

On Thu, Aug 18, 2011 at 8:37 PM, Greg KH <gregkh@...e.de> 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.
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.

>> Signed-off-by: Markus Rechberger <mrechberger@...il.com>
>
> 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.

BR,
Markus

> thanks,
>
> greg k-h
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/