Re: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

From: Jakob Østergaard (jakob@unthought.net)
Date: Sat Mar 24 2001 - 04:31:55 EST


On Fri, Mar 23, 2001 at 09:02:30PM -0800, Linus Torvalds wrote:
> In article <vbawv9hyuj0.fsf@mozart.stat.wisc.edu>,
> Kevin Buhr <buhr@stat.wisc.edu> wrote:
> >
> >The results speak for themselves:
> >
> > CVS gcc 3.0: Debian gcc 2.95.3: RedHat gcc 2.96:
> >
> > real 16m8.423s real 8m2.417s real 12m24.939s
> > user 15m23.710s user 7m22.200s user 10m14.420s
> > sys 0m48.730s sys 0m41.040s sys 2m13.910s
> >maps: <250 lines <250 lines >3000 lines
> >
> >Obviously, the *real* problem is RedHat GCC 2.96. If Linus bothers to
> >write this patch (he probably already has),
>
> Check out 2.4.3-pre7, I'd be interested to hear what the system time is
> for that one.

I was unable to compile gcc-3.0 from CVS this morning - so no tests there
for now...

First the "small" test case:
-----------------------------
2.4.2:
  gcc-2.96: -O6 -felide-constructors -fPIC
  real 7m31.748s
  user 3m52.340s
  sys 3m38.180s
  Memory consumption: ~200MB

2.4.3-pre7:
  gcc-2.96: -O6 -felide-constructors -fPIC
  real 3m52.347s
  user 3m46.120s
  sys 0m3.370s

That's pretty darn impressive Linus ! 3m38 -> 3sec ! Now if the GCC people
could only repeat that trick ;)

Then the bigger one:
-----------------------------
2.4.2:
  gcc-2.96: -O6 -felide-constructors -fPIC
  Fails compilation with "Virtual memory exhausted!" after
  real 37m28.305s
  user 23m39.930s
  sys 13m44.900s
  Memory consumption: ~300MB before failure

Note - there are no ulimits set, and the machine has more than enough memory

2.4.3-pre7:
  gcc-2.96: -O6 -felide-constructors -fPIC
  real 31m48.898s
  user 31m21.460s
  sys 0m26.980s
  Memory consumption: ~400MB - successful completion

Cool ! I can work again ;)
 
>
> It does seem like gcc-2.96 is kind of special, but considering how easy
> it is to merge anonymous memory (most of the changes were cosmetic ones
> to get nice ordering to make the merge trivial without having to
> allocate a vma that never gets used etc), it's certainly worth doing.

Beautiful !

Also, the speedup gained here is ~70 times, which may be more than the changed
allocation in gcc-3 will buy us (was that 32 times?). And, after all, there
_has_ to be some other case out there which is not as easily fixed as the GCC
one.

> Linus

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:
-
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 : Sat Mar 31 2001 - 21:00:10 EST