buhr@cs.wisc.edu (Kevin Buhr) writes:
>
> "David S. Miller" <davem@redhat.com> writes:
> >
> > It is the garbage collector scheme used for memory allocation in gcc
> > >=2.96 that triggers the bad cases seen by Serge.
>
> Ahhh! Thanks for the info.
>
> I'm still happy to help test out the patch, but I guess it's not
> likely to affect my 2.95.2 numbers much at all. Maybe I can get a
> snapshot of GCC 3.0 up and running, though, and test that out.
I pulled the "gcc-3_0-branch" of GCC from CVS and compiled Mozilla
under a 2.4.2 kernel. The numbers I saw were:
real 57m26.850s
user 96m57.490s
sys 3m16.780s
which are almost exactly the same as my GCC 2.95.2 numbers. When I
peeked at "/proc/<cc1plus>/maps" a few times, I counted ~150 lines,
not ~2000. On another, much smaller block of C++ code, I get similar
results: no dramatic change in kernel time.
Either the Mozilla codebase and my other test case don't tickle the
problem, or something has changed in 3.0's allocation scheme since
RedHat 2.96 was built.
Kevin <buhr@stat.wisc.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 23 2001 - 21:00:17 EST