lkml.org 
[lkml]   [2001]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.186 / U:0.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site