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

[Navdeep Parhar]

On Fri, Jul 31, 2009 at 11:11:26PM -0600, Scott Long wrote:
> 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.

This is informative, but I think we're talking about totally different
things.  There is no USB storage involved - the machine has a SATA disk
and that's where the core is being written to.  The USB _keyboard_
polling seems to be slowing things down.

Regards,
Navdeep