From owner-freebsd-hackers Sun Jan 20 11: 3: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id CB26837B448 for ; Sun, 20 Jan 2002 11:02:51 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.6/8.11.6) id g0KJ2jH32185; Sun, 20 Jan 2002 13:02:45 -0600 (CST) (envelope-from dan) Date: Sun, 20 Jan 2002 13:02:44 -0600 From: Dan Nelson To: Poul-Henning Kamp Cc: Duraid Madina , freebsd-hackers@FreeBSD.ORG Subject: Re: Insane performance regression? Message-ID: <20020120190244.GF81627@dan.emsphone.com> References: <000001c1a16a$ec95cc50$022a17ac@simplex> <2427.1011528090@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2427.1011528090@critter.freebsd.dk> User-Agent: Mutt/1.3.25i X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bad top-poster, no cookie. In the last episode (Jan 20), Poul-Henning Kamp said: > In message <000001c1a16a$ec95cc50$022a17ac@simplex>, "Duraid Madina" writes: > > I have a CPU-bound (well, 'malloc-bound' ;) program which takes > > about 20 seconds to run on a 'fast' PC (Pentium3-1000, Athlon > > XP1600 etc) - the source is available as > > http://www.idesign.fl.net.au/malloc_pain/malloc_pain.tar.gz (NOTE: > > you *will* need GCC 3 (or more recent) to compile it). At any rate, > > I did the cvsup/buildkernel/buildworld thing this morning (I'm > > running 5-CURRENT on an SMP box), and now that same program takes > > about half an hour to run, rather than 20 seconds. Curiously, it > > reports about 20% system time (whereas previously there was > > negligible system time) > > One, check your malloc option settings. FreeBSD-current defaults to the > AJ setting to flush out errors but this has a significant performance > hit. Duraid: were you running 4.* before and just upgraded to -current, or did you simply bring an older -current box up to date? If the latter, you might want to try building different kernels to see if you can pinpoint the commit that's causing your slowdown. You will only have to rebuild the kernel, and a binary search should let you narrow it down in under 2 hours, I'd say. I would have suggested looking at Alfred's SMP file locking commit on 2001-01-13, but if your program just does malloc()s it shouldn't be affected by that. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message