From owner-freebsd-hackers Tue Mar 27 16:41: 5 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 5FF3037B71B for ; Tue, 27 Mar 2001 16:41:03 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2S0f2s19097; Tue, 27 Mar 2001 16:41:02 -0800 (PST) Date: Tue, 27 Mar 2001 16:41:02 -0800 From: Alfred Perlstein To: Paul Saab Cc: Gersh , freebsd-hackers@FreeBSD.ORG Subject: Re: crash dump speed up patch. Message-ID: <20010327164101.P9431@fw.wintelcom.net> References: <20010327162814.A52788@elvis.mu.org> <20010327163308.N9431@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010327163308.N9431@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Mar 27, 2001 at 04:33:09PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Alfred Perlstein [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 [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