Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Mar 2001 16:41:02 -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:  <20010327164101.P9431@fw.wintelcom.net>
In-Reply-To: <20010327163308.N9431@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Mar 27, 2001 at 04:33:09PM -0800
References:  <Pine.BSF.4.21.0103271335580.3635-200000@tabby.sonn.com> <20010327162814.A52788@elvis.mu.org> <20010327163308.N9431@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help
* Alfred Perlstein <bright@wintelcom.net> [010327 16:33] wrote:
> > 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?

btw:

  ps < dumpsys()

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

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?20010327164101.P9431>