Gnome-Terminal generates high CPU usage when there is a lot of output. I have a 2.16ghz Intel Dual core. There is a process running in a gnome-terminal which itself does not take much CPU usage but generates a lot of output (perhaps 100 lines / second). In such case, Xorg-Server has very high CPU usage: between >50% on both CPUs if Gnome-Terminal is in the foreground or ~30% on both CPUs if it is in the background. Could it be that on every change in the output, Gnome-Terminal sends the *whole* data (everything in the textbox) to Xorg? That would explain the high CPU usage. On older systems (that bug occurs for me on all my systems), such a case is almost like a DoS-attack, the mouse is almost not moveable anymore.
Albert, please choose a more meaningful summary in future. "$category/$ebuild" isn't.
(Uhm, sorry, must have forgotten in this case...)
Upstream bug filled in here: http://bugzilla.gnome.org/show_bug.cgi?id=532240
Please include the neglected emerge --info. Also what graphics driver and video card is used? Also see bug 217635 if the answer for the first happens to be "nvidia", maybe this is a duplicate.
I have seen this already on many very different systems and already since quite some time. In my current system, I don't have a nvidia (it's an intel). This is my current system: macbook ~ # emerge --info Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo i686) ================================================================= System uname: 2.6.24-gentoo i686 Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz Timestamp of tree: Mon, 05 May 2008 10:30:02 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=nocona -pipe -ggdb" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=nocona -pipe -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms splitdebug unmerge-orphans userfetch" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp6.uni-erlangen.de/pub/mirrors/gentoo ftp://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/ ftp://mirror.nutsmaas.nl/gentoo/" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/private" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="7zip X a52 aac acl acpi alsa amarok amr amuled apm applet async asyncns atm automount avahi bash-completion berkdb bluetooth bonjour bookmarks bzip2 cairo cdr cli cracklib crypt cups d dbus dedicated deskbar dga dhcp divx dri dv dvd dvdr dvdread dvi eap-tls enblend encode evo exif extra-algorithms fasttrack ffmpeg flac ftp galago gd gdbm german gif glib glitz gmedia gnome gnutella gnutls gphoto2 gpm gsf gtk h323 hal haskell hddtemp hfs iconv icu id3 id3tag ieee1394 imlib injection inkjar ipv6 irda isdnlog isight jabber java javascript jit jpeg jpeg2k kde kig-scripting kqemu latex lcms libnotify lirc lm_sensors lua lzo macbook mad madwifi maps midi mmap mmx mng mozdevelop mp2 mp3 mp4 mpeg mtp mudflap musicbrainz nautilus ncurses net network networking networkmanager njb nls nptl nptlonly nsplugin ntfs ogg opengl openmp oss pam pascal pch pcre pdf perl pidgin plotutils pmu png pnm posix postgres postscript ps pth pulseaudio python qt3support qt4 quicktime rar rc5 rdesktop readline real realmedia reflection reiser4 reiserfs rtc samba screen sdl sdl-image sdl-sound sdlaudio server session sftp sharedmem sift slp smp solver sourceview speex spell spl sse sse2 ssl ssse3 startup-notification subversion svg tetex theora threads threadsafe tiff timidity tk trayicon truetype unicode unzip usb v4l2 valgrind vcd video vorbis weak-algorithms wifi win32codecs wma wmp wxwindows x264 x86 xanim xattr xcomposite xext xine xml xmlreader xorg xrandr xscreensaver xulrunner xv xvid zip zlib zsh-completion" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics evdev wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" LIRC_DEVICES="inputlirc macmini" USERLAND="GNU" VIDEO_CARDS="i810 vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Try it yourself. Start the following command: cat /dev/urandom | sed -e "s/./*/g" In gnome-terminal, when you watch the system monitor, Xorg eats up 40% of the whole system CPU usage and sed+cat only 8% (so Xorg is slowing it down here). gnome-terminal itself is only using 5%. You can even see how the sed output is hanging sometimes. If you try this in another terminal like Konsole for example, Konsole eats up 20%, sed+cat eats up 50%, Xorg 4% (this is more or less what I would expect).
Important to note (that clarifies that it is really the output of gnome-terminal): If you do the following (in gnome-terminal): cat /dev/urandom | sed -e "s/./*/g" > /dev/null Then sed+cat take up to 80% CPU, gnome-terminal and X both 0%.
Confirming on my Intel laptop... I'd say it's a vte issue. However I don't think fixing this is going to be a oneliner fix. Vte is a big library and it might require some serious profiling. @Albert, if you have some time, I suggest you provide upstream with profile logs : sysprof, oprofile, pick your poison :) Thanks
xorg.conf and Xorg.0.log please. The bug I referenced for nvidia has instructions on how to profile these things. I also think it is simply an EXA migration overhead problem as usual. exaDoMigration should be high in the profile if that is the case.
(In reply to comment #8) > Confirming on my Intel laptop... I'd say it's a vte issue. However I don't > think fixing this is going to be a oneliner fix. Vte is a big library and it > might require some serious profiling. I highly highly doubt this is a VTE issue. It has been profiled and optimized the hell out of it. To my knowledge it's the best performing terminal emulator (applications using it, that is) out there (if you don't compare apples and oranges with xterm using aliased fonts and gnome-terminal using anti-aliased fonts). > @Albert, if you have some time, I suggest you provide upstream with profile > logs : sysprof, oprofile, pick your poison :) Please profile them to this bug, not upstream.
For reference, on my machine with r200 and xorg-server git from a week ago 75% of the time is spent in libexa for the given sed from urandom snippet. Only about 2% of CPU time is spent in VTE.
Created attachment 153051 [details] my xorg.conf
Created attachment 153055 [details] my Xorg.0.log
Created attachment 153215 [details] sysprof output while gnome-terminal is running in foreground
Created attachment 153217 [details] sysprof output while gnome-terminal is running minimized
Created attachment 153219 [details] sysprof output while konsole is running in foreground
You are right, Mark, it seems that most of the time is spent in libexa, when I do the sed. Though, why does Konsole perfom so much better?
This should be a xorg-server problem then in EXA, and as such I closed the GNOME upstream bug. I haven't had time to compare the gnome-terminal and konsole results yet, however, so keeping it assigned to gnome@ from my side until then. EXA performance should get a lot better with xorg-server-1.5, but this particular use case of letting gnome-terminal flow with output seems to still be a big problem here as well (but I have quite out of date git snapshots by now, will upgrade when I get back to this bug). While gnome-terminal could probably do something different to be quicker with current EXA state, I don't think it should - EXA should get better; fixed should be what is broken, not things worked around. This seems to be the impression I get from GNOME in general as well - go fix the roots instead of working around stuff. I'm not aware in what state XAA is for the intel drivers, but you might want to give it a try with XAA instead of EXA if the intel driver still supports XAA for the purpose of research. Especially this gnome-terminal use case - other things might actually be better with EXA nowadays.
When I said earlier it was a vte issue, I meant that vte is probably doing something "wrong" with XRender. When using XAA, all XRender primitives are done by the cpu using the x11-libs/pixman library which is 100% cpu-bound : ie, very fast on a fast cpu, and slower on a slow cpu (duh!) So all operations are uniformly fast or slow, the only variable being the speed of your CPU. When using EXA, *most* XRender primitives are done on the gfx hardware... and that's when problems kick in. If vte asks for an XRender primitive that is only half implemented in hardware, then there's a fallback mechanism to pull image data from the gfx hw, do the operation using the cpu and pixman and then push the image data back to the gfx hw to finish the processing. As one can easily imagine, going back and forth between video ram and central ram is a very costly operation (even on intel chips that only have central memory!) And last time VTE was actively profiled and hacked on (1.5, 2 years ago?), XRender was not accelerated as none of the drivers had EXA yet. But things are looking bright :) - the intel driver will have TTM/GEM, a cool memory manager that will make transfers from central ram to vram (in both directions) virtually cost-free. So even with cpu fallbacks, it should be *much* faster. - all drivers (intel, radeon, ...) are picking up the pace to implement more and more EXA operations using the HW, so hopefully there will be less XRender code paths that will lead to CPU fallbacks. Now back to gnome-term/vte, maybe there are ways to temporarily work around slow XRender code paths, but my guess is that one "optimization" done on one driver/chip might just end up being worst on another driver/chip combo. EXA acceleration is a fast-moving target at the moment, which doesn't help. As far as intel drivers are concerned (I'm the maintainer) I strongly advise to join the intel-gfx ML on freedesktop to help profile the driver. Maybe do regression testing and what not. That's enough for now :)
so a few months later, where are we ?
(In reply to comment #20) > so a few months later, where are we ? > I use amd64 stable vte-0.17.4-r3 xorg-server-1.5.3-r5 xf86-video-intel-2.6.3-r1 mesa-7.3-r1 but 2.6.27 kernel (so no GEM) and vte based terminal-0.2.8.3 is very slow, with X utilizing 50% of CPU on refresh (for example while doing emerge). Have to use xterm for emerges, since they are terminal-refresh-speed bounded !
actually intel-2.6.3-r1 driver was really bad at this. With 2.7 and 2.6.28 kernel things went much better. 50k chars/sec gains which was about 20% enhancement on my laptop but no more cpu churning which made it usable again. Closing for now since it's more a x11 bug anyway and those guys will require you to run most recent xorg stuff in tree :)
