linux-kernel - Re: [PATCH v2 1/2] USB: core: add a memory pool to urb for host-controller private data

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] [day] [month] [year] [list]

Message-ID: <274d13bb.2736.196dd818307.Coremail.00107082@163.com>
Date: Sat, 17 May 2025 17:09:34 +0800 (CST)
From: "David Wang" <00107082@....com>
To: "Oliver Neukum" <oneukum@...e.com>,
	"Greg KH" <gregkh@...uxfoundation.org>
Cc: mathias.nyman@...el.com, stern@...land.harvard.edu,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v2 1/2] USB: core: add a memory pool to urb for
 host-controller private data

At 2025-05-14 17:34:21, "Oliver Neukum" <oneukum@...e.com> wrote:
>On 14.05.25 09:29, Greg KH wrote:
>  
>> No, this isn't necessarily true at all.  Allocations are fast, and if we
>> free/allocate things quickly, it's even faster.  USB is limited by the
>> hardware throughput, which is _very_ slow compared to memory accesses of
>> the allocator.
>
>If and only if we do not trigger disk IO. If you really want to give this patch
>a good performance testing you'd have to do it under memory pressure.
>
>	Regards
>		Oliver

Hi, I made some test:

Using FPS for webcam and bitrate for audio mic for measurement.
When system is under no memory pressure, no significant difference could be observed w/o this patch.
When system is under heavy memory pressure, bitrate would drop from ~760.3kbits/s to ~524.3kbits/s,
but this patch dose not make any significant difference, bitrate drops are almost the same w/o this. 
When under heavy memory pressure, my whole system gets slow....

But I think, in between no memory pressure and heavy memory pressure, there would be a point where
an extra 1k/s would kick start a chain-of-effect landing a very bad performance, it is just very hard
to pinpoint.

Using my webcam would have ~250/s memory allocation rate, and my mic ~1k/s. I am imaging a system with
several usb webcam/mic connected. There would be x*1k/s allocation if those devices are used
at the same time. (Not sure whether all allctation could be avoided under heavy usage of usb devices,
but I think good part of the allocations can be reused.)

Still think this change benefits even without a solid evidence yet.
(I have send out another version addressing Oliver's comments about urb managed by drivers)

Thanks
David