Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Aug 2003 21:33:55 -0600
From:      Tillman <tillman@seekingfire.com>
To:        sparc64@freebsd.org
Subject:   Re: ponderous 'make world' times post GCC 3.3...
Message-ID:  <20030812213355.M22214@seekingfire.com>
In-Reply-To: <p052106c8bb5d5dbc330c@[128.113.24.47]>; from drosih@rpi.edu on Mon, Aug 11, 2003 at 11:51:00AM -0400
References:  <20030807062536.GA68747@dragon.nuxi.com> <p052106c7bb59ce43912c@[128.113.24.47]> <20030809084019.GA4704@rot13.obsecurity.org> <p052106c8bb5d5dbc330c@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 11, 2003 at 11:51:00AM -0400, Garance A Drosihn wrote:
> At 1:40 AM -0700 8/9/03, Kris Kennaway wrote:
> >On Sat, Aug 09, 2003, Garance A Drosihn wrote:
> >
> >>  So, apparently the problem is something a bit more subtle than
> >>  just gcc 3.3 being slower to compile than gcc 3.2.  Apparently
> >>  the August 9th system is a lot slower at *running* than the
> >>  early system.  Do we have some other benchmarks we could run?
> >
> >This suggests that something might have been pessimized with
> >the gcc 3.3 code generation on sparc.
> 
> Well, I'm thinking that maybe we're blaming the wrong thing
> for this slowdown.  I have the results for a few more builds:
> 
>               realtime           user              sys
>              ----------      -------------    ------------
>    build 1:  347m 33.407s     283m 0.162s      53m 45.805s
>    build 2:  387m  4.205s     315m 25.441s     59m 44.648s
>    build 3: 1238m 11.386s    1064m 31.148s    136m 54.366s
>    build 4:  384m 30.479s     312m 54.407s     59m  7.338s
<snip>
> I don't know where the slowdown is occurring.  Obviously it is
> something which clobbers a buildworld, so maybe disk access or
> something like that (I have enough real memory that my system
> never pages).  That's why I was wondering if there were some
> other benchmarks we could run.  The only thing that I really do
> with my freebsd/sparc machine is buildworld's of freebsd/sparc,
> so there is nothing else where I would notice a major slowdown
> (even if it were occurring).

Disk access could indeed be a problem. Here's the build times and
bonnie++ results on the original EIDE drive in my Ultra 5:

time make buildworld:

real    1485m0.214s
user    915m40.322s
sys     98m56.775s

time make buildkernel:


real    487m44.136s
user    400m55.723s
sys     24m34.634s

bonnie++:

# bonnie++ -d /usr/scratch/ -m caliban -u 0
Version 1.93c       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
caliban        300M     8  92  1999  10   924   5    15  92  1887   6  72.4  21
Latency              2260ms     519ms    2964ms    1117ms     161ms    3688ms
Version 1.93c       ------Sequential Create------ --------Random Create--------
caliban             -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   856  68  2968  89  2478  94   811  60  2817  84  2770  94
Latency              1589ms     250ms    3365us    1674ms     477ms   10394us
1.93c,1.93c,caliban,1,1060744776,300M,,8,92,1999,10,924,5,15,92,1887,6,72.4,21,16,,,,,856,68,2968,89,2478,94,811,60,2817,84,2770,94,2260ms,519ms,2964ms,1117ms,161ms,3688ms,1589ms,250ms,3365us,1674ms,477ms,10394us

That's a slow disk. I have a 25Mhz decstation that outperforms the Ultra
5 on disk I/O. Unfortunately, I don't have drive timings from when the
buildworlds where faster to compare, so this could be a red herring :-(

Drive details:

# dmesg | grep ad0
ad0: 8223MB <ST38410A> [16708/16/63] at ata2-master WDMA2

> On build #3 I noticed that 'top' constantly reported the CPU
> was 0.0% idle.  Unfortunately I couldn't check that for build #4,
> because I didn't have a 'top' which matched the running kernel...

I also have the the 0% idle top during buildworld, even though I'm not
using -jX. It seems odd to me - with disk I/O that slow, I would think
that the CPU should be partially/occasionally idle during a buildworld.

-T


-- 
1. Get enough food to eat, and eat it.
2. Find a place to sleep where it is quiet, and sleep there.
3. Reduce intellectual and emotional noise until you arrive at the silence of
   yourself, and listen to it.
4.
	- Richard Brautigan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030812213355.M22214>