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