From owner-svn-src-head@FreeBSD.ORG Sat Aug 1 05:36:49 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C237106566C; Sat, 1 Aug 2009 05:36:49 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-px0-f196.google.com (mail-px0-f196.google.com [209.85.216.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB828FC1D; Sat, 1 Aug 2009 05:36:49 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by pxi34 with SMTP id 34so4227403pxi.3 for ; Fri, 31 Jul 2009 22:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=+kjvuD0/SUynz8GS4tOwLeQ5ftcs/xg+WJEHG/9++d0=; b=vzl+UQRay9+mVXMr8jia1cQwb5j1mwLz+SIC+VKrf2wMUOMj8KvMcjCkW3z0UhJEMP iOx1eBUtML2eipJJHITR/LFPV8VlEeIF38GU1mxqdANHU5dqh+fqgglrlK46W142/359 Jufphjve+t76FCqPoOTat+fbSqFS7XBa18L/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=xW45zYRsvfibsT23ztTCOiG8m/8xl9u/tEHl++C/mvDkFMEziIivGZg4p1JyfUhQON Ec9AnsCbplytTeQI06wG4AZiLCOvaq+JInserhYkl/hP8KjAKzjmOkLjME1Pu4rdnDt+ 4gUJ6JOrZ7esnpl1Mxyb0K4BFGQLzFBAWOD7U= Received: by 10.114.169.5 with SMTP id r5mr989587wae.136.1249105008935; Fri, 31 Jul 2009 22:36:48 -0700 (PDT) Received: from doormat.home (c-76-126-210-244.hsd1.ca.comcast.net [76.126.210.244]) by mx.google.com with ESMTPS id g25sm6414926wag.43.2009.07.31.22.36.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 22:36:48 -0700 (PDT) Date: Fri, 31 Jul 2009 22:36:44 -0700 From: Navdeep Parhar To: Scott Long Message-ID: <20090801053644.GA9150@doormat.home> Mail-Followup-To: Scott Long , Dmitry Marakasov , Alfred Perlstein , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org References: <200907300014.n6U0EZ77086341@svn.freebsd.org> <20090801022914.GB93222@hades.panopticon> <4A73AF67.3010508@samsco.org> <20090801050053.GB8399@doormat.home> <4A73CE7E.9060609@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A73CE7E.9060609@samsco.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alfred Perlstein , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Dmitry Marakasov , src-committers@FreeBSD.org Subject: Re: svn commit: r195960 - in head/sys/dev/usb: . controller input X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 05:36:50 -0000 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