Slow exaOffscreenAlloc ?

[Eric Anholt]

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 Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081208/71e8bc7e/attachment.pgp>