svn commit: r195960 - in head/sys/dev/usb: . controller input

[Scott Long]

Navdeep Parhar wrote:
> On Fri, Jul 31, 2009 at 08:58:47PM -0600, Scott Long wrote:
>> Dmitry Marakasov wrote:
>>> * Navdeep Parhar (nparhar at gmail.com) wrote:
>>>
>>>> This has slowed down core dumps very significantly.  What used to take 10-15s on
>>>> my system now takes around 3 minutes.
>>> Same here.
>>>
>> Likely because prior to polling being implemented, each i/o was done
>> blindly and completed immediately instead of waiting for actual
>> confirmation from the hardware.  Crashdumps have been slow for a
>> number of years, thanks to a fundamental change in how they are done.
>> Until now, USB was cheating and making them look fast.
> 
> I'm afraid I did not understand your email.  I was talking about
> crashdump time differences between yesterday and the day before, not
> "over a number of years."  Are there any other issues involved here?
> 

Crashdumps work by the crashdump routine sending an i/o one-at-a-time to
the disk driver, waiting for a completion response between each i/o.
Polling in the disk driver is used to detect when the disk hardware has
completed each i/o request.  Since it is done completely serially and
completely synchronously, it's very slow because it has to wait for the
hardware to process each i/o, one at a time.

Prior to yesterday, the usb2 stack did not implement polling.  The umass
disk driver completely ignored polling, and always immediately returned
success.  So instead of waiting for the hardware to complete each
crashdump i/o request, it immediately returned success and allowed the
crashdump routine to send a new i/o.  It was short cutting the required
process.  Now that polling is in place, the shortcut is gone, and
crashdumps on USB are back to being slow, just like on every other disk
driver.  The shortcut is fast, but it's also unsafe; it's bypassing the
guarantee that every i/o is getting written without error and without
overrunning the speed of the disk media.

I mention "over a number of years" because the crashdump routine wasn't
always designed to be so slow.  But, that's how it is now, and there
isn't much that can be done in the USB driver to fix it, short of going
back to the unsafe shortcut.

Scott