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]

Date:	Mon, 12 Sep 2011 12:18:02 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Increase usbfs bulk buffer size

Hi,

I'm a little bit curious why you guys are just ignoring this. We will
do some performance tests within the next days and submit the results.
Isochronous uses way bigger allocations using kmalloc and you seem to
be okay with it, but for bulk 1/3rd of it is not okay?! It doesn't
make sense to me.
The impact of changing it from

> Do you have real numbers and example programs that show the difference
of this kernel change making a real difference?

we do have we've been providing our applications for 3 years, the
device support is directly implemented into our streaming application.
Our customers were even the first ones who recognized when USBFS was
broken in the past.
http://code.google.com/p/wl500g/source/browse/trunk/kernel/247-usb-devio-max-isoc.patch?spec=svn1907&r=1907

this patch introduced some significant performance improvement for
Isochronous transfers in the past, now it would be nice to have the
same one (note 1/3rd that max bufsize only!) for Bulk.
Our isochronous devices are already running day and night with that
maximum for a very long period of time.

Markus

On Wed, Aug 31, 2011 at 8:57 AM, Markus Rechberger
<mrechberger@...il.com> wrote:
> Greg, Oliver,
>
> can you justify why 190K is acceptable for Isochronous (which has been
> in the kernel for a long long time now) but less than 50k is suddenly
> not acceptable for bulk when using USBFS? Especially while the wild
> out there already approved that 190K is okay even on embedded systems?
> That's the only thing I would like to know :-)
>
> We made many tests here (and have many more customers using Isoc 190k
> buffers) and memory allocation has a much better performance instead
> of pushing ioctls forward/backward for reading those small packets.
> I do understand your concern but from my point and experience with it
> (we've been using it for 3 years so far) it does not cause any
> problem. We reached the 1k amount of users using 190k Isoc buffers a
> long time ago, those are pushing 170 Mbit a second. The bulk purpose
> is for 80mbit a second only.
> I would just like to have all supported modes with performance and not
> too many changes. Currently we only get good performance with
> isochronous, bulk USBFS performance could just be better with Linux,
> our software works well enough with Mac, Solaris and FreeBSD with Bulk
> and Iso.
>
> BR,
> Markus
>
> On Fri, Aug 19, 2011 at 12:45 PM, Markus Rechberger
> <mrechberger@...il.com> wrote:
>> On Fri, Aug 19, 2011 at 8:23 AM, Oliver Neukum <oliver@...kum.org> wrote:
>>> Am Mittwoch, 17. August 2011, 19:44:16 schrieb Markus Rechberger:
>>>> I understand that USBFS is not 100% optimized, although we are already
>>>> using 3-4 times that much buffer with isochronous and it was working
>>>> fine for years so far as long as the system doesn't run out of memory
>>>> .. but even kerneldrivers would have issues with it in such a
>>>> situation.
>>>
>>> The problem is not what happens on your test system dedicated to this use.
>>> There it'll work. But you allowed everybody else to make the kernel request
>>> the second largest chunk of memory there is. On a otherwise busy system
>>> with fragmented memory this is not good.
>>>
>>> As I said, you want scatter/gather if you need this.
>>> There still would be the problem with the API, but if this is really a problem,
>>> you could define a new ioctl()
>>>
>>
>> let's say there are a few thousand users of the 190k isochronous implementation.
>> I don't want to add more complex code to the kernel, if it's not
>> accepted I'm okay with it,
>> since I know the performance impact I can recommend it to those who
>> are interested in it.
>> Our software works without it anyway, and Bulk is just for special use
>> in our case.
>>
>> Best Regards,
>> Markus
>>
>
--
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/