On Tue, Jul 22, 2003 at 11:44:59AM +0300, [EMAIL PROTECTED] wrote: > After a few minutes of playing with xfontsel, my X hanged up. > Keyboard and mouse didn't react on my action. > M-C-fX and M-C-Backspace didn't work too. > > But it seems my computer was still alive because I was able connect to it > from a remote host. I did it and a top of top looked like this > > 24622 root 20 -10 326M 24M 10392 R < 99.2 2.4 38:22 XFree86 > ^^^^
Please read the Debian X FAQ. /usr/share/doc/xfree86-common/FAQ.gz ---------------------------------------------------------------------- *) Why does the X server take up so much memory? (Especially heard from KDE users with large monitors, many workspaces, and a different picture in the root window of each workspace.) Answer courtesy of Mark Vojkovich of the XFree86 Project, Inc.: The X Window System is a client-server window system. The memory for pixmap data resides on the server side instead of the client side. If you have 8 1600x1200 32bpp root window images that's 61 Megabytes. It resides in the server instead of the client, unless they are shared memory pixmaps, in which case it will be counted on both the server and client side. Obviously this data has to be stored someplace. It's not like it can just disappear when you're not using it. If they were stored on the client side instead, people would be complaining about KDE memory usage. Additionally, Sean McGlynn of the KDE Project offered assistance: Please direct such users over to KDE's mailing lists - http://www.kde.org/mailinglists.html - and we can try and investigate/resolve their issues fully. David B. Harris of Debian also has these remarks: Something worth noting is also the concept of "leaking". This will be a term familiar to some and unknown to others. Basically, as processes run they may dynamically allocate memory for some purpose or other. If they allocate some memory, but never *de-allocate* it, even after they're done using it, then over time the memory used by that process will increase. Since hardware/video drivers in XFree86 are responsible for some of this allocation and de-allocation, a badly-written driver can increase the memory used by the XFree86 process. The closed-source nVidia drivers are particularily bad for this; I've seen XFree86 memory usage triple during a week-long session. Keep in mind that this isn't the end of the world. Unless it's an extremely badly-written driver, memory allocated by the driver which doesn't get de-allocated (but stops being actively used) will be swapped out. So the amount of physical RAM the XFree86 process will use won't increase much (if at all) due to these drivers. And finally, these remarks from Mike A. Harris of Red Hat Software: I'd like to add to that another frequently reported problem of XFree86 consuming a lot of memory. Many people report X uses 64Mb+ of memory and can't see any reason why it should. They blame X for being bloated, etc. Digging into it more however, 99 times out of 100, they are using the output of top or procps or similar utility do show how much memory XFree86 is consuming. Unfortunately, the memory reported as used in top/ps output is interpreted solely as being system RAM and/or swap, and that is very misleading as it is not true. The memory shown by top, which users are misled into believing is memory used up by X, is an amalgamation of the video card's own memory, and memory mapped I/O regions, as well as the actual memory used by the X server, pixmaps, and various other things. It is not at all uncommon for a modern 64Mb video card, to have X's memory usage appear to be 100Mb or more, when in reality, 64Mb of that is video RAM, and 16-32Mb possibly mmapped registers. Most developers such as ourselves are aware of this, however most end-users are not. On Linux a user can view the memory map breakdown by logging in as root and looking at the file: cat /proc/$(pidof X)/maps That gives a fairly detailed breakdown of the memory map of the X server process, and what actual amount of memory is being used, etc. The exact meaning of the contents of the proc maps file is left as an exercise for the curious reader. ;o) Reading the kernel sources which implement it is about the best manual I know of. ---------------------------------------------------------------------- The hang is probably a bug, but your use of top to diagnose the problem does not elucidate the situation, for the reasons explained above. -- G. Branden Robinson | I've made up my mind. Don't try to Debian GNU/Linux | confuse me with the facts. [EMAIL PROTECTED] | -- Indiana Senator Earl Landgrebe http://people.debian.org/~branden/ |
pgp00000.pgp
Description: PGP signature
