Mike Cherba wrote,
>I noticed this when I was booting a system attached to a USB serial
>device, but eventually localized the issue to xterm itself. Basically
>when you put a lot of text through an xterm the cpu usage on gutsy goes
>way up. like 100%. I've tried the same thing with the generic terminal
>app gnome-terminal and the cpu usage is much lower. This seems odd.
>I'm wondering if there is something broken or at least terribly
>sub-optimal in one of the libraries used.
>
>I'm running KDE and can reproduce this symptom at will simply by running
>"du -ah /" in the two different terminals. (xterm & gnome-terminal)
I doubt it's a general xterm problem...on my Slackware 11.0 system, the
problem doesn't occur. I did "du -ah /" in an xterm window, and while it
was running, xterm never exceeded 10% CPU usage, and was usually around 5%
to 7%. This was comperable to the CPU usage of du itself.
I can't test gnome-terminal because I don't have it...a couple of releases
ago Slackware decided (mostly for disk space reasons) that they would only
ship KDE, not Gnome.
>It looks like the are 4 shared libraries that xterm uses that
>gnome-terminal doesn't.
> libXaw.so.7 => /usr/lib/libXaw.so.7 (0xb7f46000)
> libXmu.so.6 => /usr/lib/libXmu.so.6 (0xb7f30000)
> libXt.so.6 => /usr/lib/libXt.so.6 (0xb7ed1000)
> libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb7b73000)
>and a whole raft of libraries that gnome-terminal uses that xterm
>doesn't.
I suppose one of these could be the culprit, but I doubt it's likely.
* libXaw is the Athena Widgets library (the widget set that xterm uses).
* libXmu contains a few simple X utility functions.
* libXt is the X Intrinsics Toolkit, a widget-set-writing library that
underlies Athena Widgets.
* libXpm is the X Pixmap library. This is probably used mostly for
drawing the xterm icon if you iconify the window.
>I'm going to rebuild my xterm and try profiling it to see where all the
>cycles are going. top shows them as being associated with Xorg itself.
Are you using the X driver designed for your particular graphics card, or
are you using the generic VESA framebuffer driver? If there's an X driver
for your card, it's probably a lot more optimized than the framebuffer
driver...in particular, it can probably program your card's hardware
blitter to scroll the xterm window, while the framebuffer driver would
have to copy the pixels in software. (Your du command does LOTS of
scrolling.)
>[EMAIL PROTECTED]:~/minicom-2.2# ldd /usr/bin/xterm
> linux-gate.so.1 => (0xffffe000)
> libXft.so.2 => /usr/lib/libXft.so.2 (0xb7fcc000)
> libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7fa1000)
> libXaw.so.7 => /usr/lib/libXaw.so.7 (0xb7f46000)
> libXmu.so.6 => /usr/lib/libXmu.so.6 (0xb7f30000)
> libXext.so.6 => /usr/lib/libXext.so.6 (0xb7f22000)
> libXt.so.6 => /usr/lib/libXt.so.6 (0xb7ed1000)
> libSM.so.6 => /usr/lib/libSM.so.6 (0xb7ec9000)
> libICE.so.6 => /usr/lib/libICE.so.6 (0xb7eb1000)
> libX11.so.6 => /usr/lib/libX11.so.6 (0xb7dc0000)
> libncurses.so.5 => /lib/libncurses.so.5 (0xb7d7b000)
> libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c31000)
> libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7bc1000)
> libz.so.1 => /usr/lib/libz.so.1 (0xb7bac000)
> libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7ba4000)
> libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7b84000)
> libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb7b73000)
> libXau.so.6 => /usr/lib/libXau.so.6 (0xb7b70000)
> libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7b6b000)
> libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7b67000)
> /lib/ld-linux.so.2 (0x80000000)
> libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7b4f000)
Slackware 11.0's xterm is a little different...it doesn't link with libXau
(the X authorization library), libXdmcp (the X display manager control
protocol), or libpthread (the threads library).
My first suspicion is that top is telling you the truth when it says that
your cycles are being eaten up inside Xorg, in which case a profiling
version of xterm probably won't tell you much that's helpful. I suspect
the place to start looking is in /etc/X11/xorg.conf.
- Neil Parker
_______________________________________________
EUGLUG mailing list
euglug@euglug.org
http://www.euglug.org/mailman/listinfo/euglug
