Date: Fri, 31 Jul 2009 23:11:26 -0600 From: Scott Long <scottl@samsco.org> To: Scott Long <scottl@samsco.org>, Dmitry Marakasov <amdmi3@amdmi3.ru>, Alfred Perlstein <alfred@FreeBSD.org>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r195960 - in head/sys/dev/usb: . controller input Message-ID: <4A73CE7E.9060609@samsco.org> In-Reply-To: <20090801050053.GB8399@doormat.home> References: <200907300014.n6U0EZ77086341@svn.freebsd.org> <d04e16b70907310045y635245efob33b10464c22524f@mail.gmail.com> <20090801022914.GB93222@hades.panopticon> <4A73AF67.3010508@samsco.org> <20090801050053.GB8399@doormat.home>
next in thread | previous in thread | raw e-mail | index | archive | help
Navdeep Parhar wrote: > On Fri, Jul 31, 2009 at 08:58:47PM -0600, Scott Long wrote: >> Dmitry Marakasov wrote: >>> * Navdeep Parhar (nparhar@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A73CE7E.9060609>