Not solved!

[Nix]

On 5 Feb 2009, Michel Dänzer verbalised:
> On Thu, 2009-02-05 at 18:23 +0000, Nix wrote:
>> 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

Yeah, that does it. It also used to lock up kded 3.5.x so I was rather
chary of ever switching VTs, but that seems to have got fixed as well
sometime in the six months since I dared do it last. (I'm not sure what
effect VT switching could have on kded, but the effect was quite
consistent and rather damaging to the desktop.)

> EXA offscreen memory is probably fragmented. I have a defragmentation
> patch that I hope to clean up and push one of these days.

A kludgy approach would be to do whatever gets done on VT switch (dump
and repopulate the entirety of EXA offscreen memory?) whenever a
significant fraction of allocation requests start to fail due to
fragmentation.

(It seems that this would be an easy case to detect.)

It certainly doesn't log anything about this case. Right now the only
EXA-related message I see in the logs after X startup is a single lonely

exaCopyDirty: Pending damage region empty!

which is presumably unrelated.