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

["David Wang" <00107082@163.com>]

At 2025-05-14 17:34:21, "Oliver Neukum" <oneukum@suse.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