Date: Tue, 27 Mar 2001 16:33:09 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Paul Saab <ps@mu.org> Cc: Gersh <gersh@sonn.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: crash dump speed up patch. Message-ID: <20010327163308.N9431@fw.wintelcom.net> In-Reply-To: <20010327162814.A52788@elvis.mu.org>; from ps@mu.org on Tue, Mar 27, 2001 at 04:28:14PM -0800 References: <Pine.BSF.4.21.0103271335580.3635-200000@tabby.sonn.com> <20010327162814.A52788@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <ps@mu.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010327163308.N9431>