Not solved! (was Re: client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?)

[Michel Dänzer]

On Thu, 2009-02-05 at 18:23 +0000, Nix wrote:
> I said:
> > 1.5: EXA, 16,     AA: dixLookupPrivate 23.17
> >                       generally much faster than XAA, occasionally degrades to
> >                       XAA speed
> > 1.5: EXA, 24,     AA: dixLookupPrivate 26.83
> > 1.6: EXA, 16,     AA: exaBufferGlyph 5.74 (X: 49.42); xterm: 9.48; kernel: 20.10
> >                       *********************************************************
> >                       ***********************
> > 1.6: EXA, 24,     AA: exaBufferGlyph 4.82 (X: 57.88); xterm: 7.09, kernel: 33.5
> >                       App speed: 50, considerably slower than 16bpp. X seems to
> >                       be spending longer in the kernel.
> >                       **************************************************
> 
> These lovely results continued for about a day, then abruptly hit a
> wall. Text rendering is now as slow as it ever was, or slower, taking
> five seconds or so to repaint the screen once in order to scroll down a
> single line :((( e.g. doing a CPAN upgrade, the top few lines of
> sysprof are:
> 
> [perl]                29.90
> [X]                   25.80
> exaOffscreenAlloc     10.78
> exaOffscreenFree      8.45
> 
> i.e. X is slowing my jobs down by almost half.
> 
> I think it's plain where the problem is: the exaOffscreen*() lines are
> both new, at least at this position in the profile...

Does VT switching to console and back restore the original? If so, the
EXA offscreen memory is probably fragmented. I have a defragmentation
patch that I hope to clean up and push one of these days.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer