Performance issues with XDefineCursor and XtAddTimeOut

Guy Léonis Guy.Leonis at spacebel.be
Fri Mar 4 05:52:24 PST 2011


Hello,

I went through all FAQ and Archives without being able to find anything about my performances issues.
I apologize in case I did my searches the wrong way.
If you need more information on my side, I will do my best to provide you with the requested files and logs.

Context:
========
I am working on a European Space Agency project. I am currently trying to migrate our application from Red Hat Enterprise Linux (RHEL) 3.0 running perfectly on an IBM T31p laptop to a more modern tandem laptop/linux OS. I am currently trying RHEL 5.5 (not RHEL 6.0 because of other issues) and Fedora 14. See attached *uname* files for kernel versions, *rpm* files for installed Xorg packages, and *Xorg.0.log files for Xorg server log.
The laptop computer I migrate on is a Lenovo T61p (T7700 Core 2 Duo at 2.4 GHz with PCI Express x16 - NVIDIA Quadro FX 570M video card).
Important notice: our application code has not been modified at all during the migration process, only the -m32 compilation flag was added.

Issue 1 (help):
===============
In the frame of our application, during upload periods, the cursor is updated (XDefineCursor + XFlush) either every tenth of a second or every half of a second with a new value decremented from 100% to 0%, an efficient way to provide feedback to the user (astronauts!) during progress of background tasks.
On the old A31P, this was perfect (no blinking, no delay, no freezing, not sluggish at all).
On the T61p with RHEL 5.5 (Xorg server 1.1.1), this is still perfect.
On the same T61p with FC14 (Xorg server 1.9.0), this is impossible to manage. The cursor disappears for periods of about half a second at each update, making the cursor deeply blinking, impossible to follow when moving the mouse, extremely difficult to point on e.g. a screen button.
This is true even with a 0% CPU application (see Issue 2).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>  Any suggestion to solve that issue would be welcomed.  <<<<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Issue 2 (info):
===============
In the frame of the same application, there are 2 threads. The first thread, which is totally free of X calls, manages a PCMCIA MIL-1553-STD bus card and stores uploaded data. The second thread, which gather all X calls, displays uploaded data. The X thread polls the data buffer every millisecond thanks to XtAddTimeOut(1,...).
On the old A31P, this was perfect (no performance issue, CPU use of 0.1% or so). To be honest, the TO callback was actually activated only every 10 milliseconds.
On the T61p with RHEL or FC14, this is not nice. This time, the TO callback is activated every millisecond but the X thread consume 100% of the CPU time provided by one core.
I have used XtAddTimeOut(10,...) instead, and the CPU load goes down to ~4% without visible impact at user level. This is a fine work around for our application.
In any cases (i.e. any CPU load), this is not a true problem, the X thread being fully responsive to user actions, display updates and (fixed) cursor moves. By the way, 100%, 4% or even a lower CPU load doesn't impact the cursor issue (see Issue 1).
I have attached a minimum code example to evidence the issue (usage: xtoperfo #loop interval), together with files created by gprof under FC14 showing that each call to XtAddTimeOut generates about 150 loops within XtMainLoop (shorter interval means more loops!). See attached fc14.xtoperfo*log files as examples (10000 loops with both 1 and 10 ms intervals).
It should be possible to suppress much of this overhead (e.g. see RHEL 3.0 implementation) and then to avoid having a 100% CPU load.


Thank you in advance for support. Best regards,

Guy Léonis 




Spacebel                    Tel   : +32-26 58 20 27
I. Vandammestraat 7 bus 1   Fax   : +32-26 58 20 90
B-1560 Hoeilaart            email : Guy.Leonis at spacebel.be
BELGIUM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rhel55.uname.log
Type: application/octet-stream
Size: 98 bytes
Desc: rhel55.uname.log
URL: <http://lists.x.org/archives/xorg/attachments/20110304/7d3339e5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc14.uname.log
Type: application/octet-stream
Size: 106 bytes
Desc: fc14.uname.log
URL: <http://lists.x.org/archives/xorg/attachments/20110304/7d3339e5/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rhel55.Xorg.0.log
Type: application/octet-stream
Size: 45639 bytes
Desc: rhel55.Xorg.0.log
URL: <http://lists.x.org/archives/xorg/attachments/20110304/7d3339e5/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc14.Xorg.0.log
Type: application/octet-stream
Size: 80341 bytes
Desc: fc14.Xorg.0.log
URL: <http://lists.x.org/archives/xorg/attachments/20110304/7d3339e5/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc14.xtperfo.10.log
Type: application/octet-stream
Size: 63679 bytes
Desc: fc14.xtperfo.10.log
URL: <http://lists.x.org/archives/xorg/attachments/20110304/7d3339e5/attachment-0004.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fc14.rpm-xorg.txt
URL: <http://lists.x.org/archives/xorg/attachments/20110304/7d3339e5/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xtoperfo.c
Type: application/octet-stream
Size: 2131 bytes
Desc: xtoperfo.c
URL: <http://lists.x.org/archives/xorg/attachments/20110304/7d3339e5/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc14.xtoperfo.1.log
Type: application/octet-stream
Size: 63677 bytes
Desc: fc14.xtoperfo.1.log
URL: <http://lists.x.org/archives/xorg/attachments/20110304/7d3339e5/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc14.xtoperfo.10.log
Type: application/octet-stream
Size: 63679 bytes
Desc: fc14.xtoperfo.10.log
URL: <http://lists.x.org/archives/xorg/attachments/20110304/7d3339e5/attachment-0007.obj>


More information about the xorg mailing list