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
        [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to