From owner-freebsd-hackers Tue Mar 27 16:33:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 504E437B71A for ; Tue, 27 Mar 2001 16:33:10 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2S0X9V18753; Tue, 27 Mar 2001 16:33:09 -0800 (PST) Date: Tue, 27 Mar 2001 16:33:09 -0800 From: Alfred Perlstein To: Paul Saab Cc: Gersh , freebsd-hackers@FreeBSD.ORG Subject: Re: crash dump speed up patch. Message-ID: <20010327163308.N9431@fw.wintelcom.net> References: <20010327162814.A52788@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010327162814.A52788@elvis.mu.org>; from ps@mu.org on Tue, Mar 27, 2001 at 04:28:14PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Gersh (gersh@sonn.com) wrote: > > Ive writen a quick patch for dev/ata/ata-disk.c:addump under > > 4.0-stable (03/26/01) which is considerbally faster. > > > > I did dumps on a SMP system with 512 megs of ram. > > > > Old: 201 seconds. > > New: 59 seconds. > > > > What I could gather from talking to people over irc/email about the > > problem was that there was a DELAY(1000) in between each printf > > to deal with problems with serial connections to the debugger. The > > soultion I came up with simply to display a smaller ammount of printf's > > the output looks like this: > > > > Dump in progress, percentage complete: 10 20 30 40 50 60 70 80 100. Done. > > > > The dump_stats() routine probally belongs in some kern/subr_whatever.c > > and should probally be used in the other dump routines for da/ide etc. * Paul Saab [010327 16:28] wrote: > This does not include the write combined crashdump code. Please update > your sources and you will see this change isn't necessary. If he's able to make a 2 minute difference by reducing the amount of calls to DELAY, why not? The only reason I can see is that output the block addresses could do something to assist in detecting problems in the crashdump routine. perhaps this can be defualt to off? but tuneable for those of us doing devel work? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message