tree 6866c84a8b48818f97e9aa3c43c78aa51e050a34
parent 8635c016db451dd36533a8708eea0bf4f68c001e
author Peter Collingbourne <pcc@google.com> 1707867637 -0800
committer Peter Collingbourne <pcc@google.com> 1707955787 -0800

fastboot: Increase maximum usbfs bulk size for writes to 256KiB

With a device capable of saturating the bus at SuperSpeed+,
the next bottleneck is the fixed (size-independent) overhead of
the usbfs ioctl() system calls, which includes entering/exiting
the kernel, allocating/deallocating a contiguous buffer for DMA,
configuring/deconfiguring the IOMMU and issuing the DMA to the HC. In
order to saturate the bus from the host software perspective, we must
reach the schedule() call in reap_as() before the next interrupt from
the HC indicating the completion of the URB.

In my experimental setup, with an SS+ capable host and device
and 16 KiB URBs, we reach the schedule() call in 25us, but the
URB is serviced in an estimated 16us, so we lose roughly a third
of the bandwidth. Increasing the URB size to 64KiB there are
65us between interrupts and 55us until schedule(). This means
we usually reach schedule() in time but not always, so we lose a
bit of bandwidth. Increasing it again to 128KiB and we have 128us
between interrupts and 65us until schedule(), so we're now comfortably
saturating the bus. In order to account for differences between hosts,
this CL uses a doubled maximum of 256KiB.

With larger allocation sizes we now risk contiguous allocation
failures, so I implemented a fallback where we try smaller sizes if
a larger one fails.

With this CL download speeds on my hosts are now around 980 MB/s over
SS+ and 440 MB/s over SS.

Bug: 325128548
Change-Id: Ie5ad480c73f2f71a50ce7f75ffb4aaa93ded2f0b