Slow exaOffscreenAlloc ?
eric at anholt.net
Mon Dec 8 15:55:13 PST 2008
On Tue, 2008-12-09 at 00:40 +0100, Zdenek Kabelac wrote:
> 2008/12/9 Eric Anholt <eric at anholt.net>:
> > On Mon, 2008-12-08 at 12:32 +0100, Zdenek Kabelac wrote:
> >> Hi
> >> Recently I've noticed that scrolling in firefox is getting very very
> >> slow on some pages - especially those with some static background on
> >> the sides of pages. So I've started oprofile - and to my surprise the
> >> most of the time has been spent in two Xorg libexa functions:
> >> Of course I could be completely wrong in my interpretation of these
> >> oprofile results - from the fast look into the exa/exa_offscreen.c
> >> it seems like a major time is spent in some loop going through
> >> possible quite large list of offScreenAreas?
> >> I'm running the latest fedora rawhide xorg-x11-server-Xorg-1.5.3-5.fc10.x86_64
> >> X.Org X Server 1.5.3
> >> Release Date: 5 November 2008
> >> and linus-git kernel tree 2.6.28-rc7
> >> Any ideas, solution ?
> > My suspicion is that firefox is chewing through a lot more temporary
> > pixmaps than it used to. I was just doing some profiling with UXA for
> > scrolling in the slashdot comments section, and while things seem to be
> > better than described by people using EXA, I'm still seeing unimpressive
> > performance and indications that ff is using a lot of pixmaps (working
> > set exceeding my 180MB of aperture space). We've got a few ideas to
> > improve things for UXA performance still, so it may get better. It's
> > already a win over EXA, since EXA's stuck with only 50MB of aperture
> > space.
> > On the other hand I've still got rendering issues with UXA, so you've
> > been warned before you go playing with it.
> >> Zdenek
> >> CPU: Core 2, speed 2200 MHz (estimated)
> >> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a
> >> unit mask of 0x00 (Unhalted core cycles) count 100000
> >> samples % image name app name
> >> symbol name
> >> -------------------------------------------------------------------------------
> >> 35766 26.1526 libexa.so Xorg
> >> exaOffscreenAlloc
> >> 35766 100.000 libexa.so Xorg
> >> exaOffscreenAlloc [self]
> > This says to me that you're stuck allocating/freeing offscreen memory
> > space to handle a working set that exceeds the size of your EXA
> > offscreen space. UXA makes the pixmap offscreen space be unified with
> > 3D and every other GPU activity.
> So there is nothing which could improve the performace here - i.e.
> better allocation logic instead of scanning possible very long list of
> chunks to allocate/free pixmaps ?
> Should I open bugzilla for firefox - so they could play more nicely here?
Nope, on further examination ff is doing perfectly sensible cairo
rendering and we're handling it poorly.
We're moving from EXA to UXA, which fixes a lot of the performance
problem by having an allocator that doesn't suck. The remainder of the
fix would be accelerating trapezoids.
eric at anholt.net eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the xorg