Bug 4942

I'll second this.  Just limiting the amount of RAM that the Xserver will use is
a good start.  Even better would be a way for it to push old and large pixmaps
out as needed.  Firefox isn't the only offender here; there seem to be a lot of
apps lately that don't clean up after themselves.  Is there anything in the X
protocol that would allow the Xserver to "age out" pixmaps?

The best I can think of that we can do and not violate the protocol is to keep
track of the total amount of pixmap data allocated by each client, and when a
particular client tries to go over that limit, start returning BadAlloc for any
more CreatePixmap requests - which will cause most clients to exit, since they
don't handle XErrors.   The per-client limit would of course need to be
configurable and probably optional, but I don't think it would be that hard to
implement.

Trying to set memory requirements on a client-by-client basis will be a nice
fine-grained control, but will create the problem that to control clients
effectively, will require quite a bit of thought (i.e. Firefox I want to limit
to X megs, gpdf I want to limit to Y megs, etc.), and could require a large
configuration section.  If you're simply going to set a single "no client can
consume more than Y megs" parameter, you'll have to set it so high that it won't
end up being a useful metric.

Better (at least from our point of view), would be to set a "total amount of
pixmap memory available" parameter.  When the pool gets close to the limit set,
the  BadAlloc result is returned.  That way, the user doesn't need to worry
about per-client config.

Ideally, it'd be nice to have and and/or on both per-client and total-pool
settings, but for thin clients, at least, a total-pool setting is better.

*** Bug 2524 has been marked as a duplicate of this bug. ***

One refinement of this idea would be to add pixmap pageout to the server directly.

I would rather like to see a separate memory pool per client where all
allocations for a given client are satisfied from (except, perhaps for data
shared by several clients). That way when a client exits (or killed due to
memory abuse) the virtual size of the xorg process is reduced too. I reckon
per-client memory pool would be a good solution to memory fragmentation in xorg.

I use Debian Etch with Xorg 7.0.22.
Please decide upon a solution! Try the most simple (global cache size limit for
Xorg) first, and then we will see if our PCs become usable again.
Too many people end up like me after hours, days, or weeks, depending on the
power (memory and CPU) of their PC: Xorg has put so much stuff in cache that the
computer becomes 10 times slower, and I am not exagerating! My duron@1750Mhz
with 1Gbytes and matrox G400 really feels much slower than my old Celeron 400.
This is incredible, horrible, and an emergency. My computer becomes totally
unusable after 2 weeks, but before that it became unusable several times because
of amule, which after days increases the memory and CPU consumption of Xorg a
lot (30% CPU usage for X, ten times more than normal) and I have to kill amule,
and the same could have been said of Mozilla if it did not crash regularly,
freeing some memory. I admit I leave many programs open, and some of them like
Mozilla and Firefox have terrible memory consumption, but what am I supposed to
do: turn off my PC regularly like at the nightmarish time of Windows 98, or kill
programs regularly? What kind of a computer experience is that? Don't worry: I
wrote to the Mozilla and amule developpers a long time before writing to you!
Exemples of people experiencing huge memory usage by X and very slow computer:
http://ubuntuforums.org/showthread.php?t=92844
http://ubuntuforums.org/showthread.php?t=85869
And I found many many more desperate people while googling for a solution.
Keep up your important work for all of us, and please save us! And contribute to
decrease the energy usage of computers and the memory consumption! It is
important for planet Earth! Every time we are forced to buy more memory the
computer industry releases more horrible toxic pollutants into Nature.


Top:
top - 18:04:10 up 17 days, 16:57,  3 users,  load average: 6.28, 6.43, 6.23
Tasks: 158 total,   9 running, 149 sleeping,   0 stopped,   0 zombie
Cpu(s): 79.1% us, 12.3% sy,  1.7% ni,  0.0% id,  0.0% wa,  0.7% hi,  6.3% si
Mem:   1036752k total,  1027564k used,     9188k free,     5024k buffers
Swap:  3028244k total,  2440072k used,   588172k free,   131608k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27590 rich      16   0  803m 413m  16m R 36.9 40.9 477:46.95 mozilla-bin
23481 rich      25   0  158m  80m 6968 R 18.9  7.9 150:11.98 amule
21549 rich      16   0 32548 7780 5948 S 14.3  0.8 879:22.57 ksysguard
 6859 gkrellmd  16   0 11768  888  716 S  6.3  0.1   2079:52 gkrellmd
 7520 rich      16   0  104m  10m 6292 S  6.3  1.0 187:47.60 kicker
25683 rich      15   0  304m  39m  34m R  6.0  3.9 620:50.09 qemu
 7271 root      16   0 1396m  52m 4720 R  5.0  5.1   1720:59 Xorg
21556 rich      15   0  3052  884  708 S  3.3  0.1 133:53.03 ksysguardd
 6514 rich      16   1  262m 124m  13m R  1.7 12.3 153:13.94 firefox-bin
 7516 rich      15   0 42280 6720 4620 S  0.3  0.6  10:11.28 kwin
 7532 rich      15   0 35504 6828 4900 R  0.3  0.7   0:15.88 konsole
 7582 rich      15   0 38796 4512 3384 S  0.3  0.4 124:48.41 gkrellm
 7810 rich      15   0 58644 1812 1548 R  0.3  0.2  28:46.51 xmms
 8545 rich      15   0 26720 2588 2520 R  0.3  0.2  16:33.10 gksu
24100 debian-t  15   0 11088 8528 1608 S  0.3  0.8   4:14.98 tor
19865 root      15   0 34896  920  856 S  0.3  0.1   0:49.01 apt-listbugs
 7705 rich      15   0  2388 1164  840 R  0.3  0.1   0:00.10 top


After killing Mozilla:

top - 18:27:11 up 17 days, 17:20,  3 users,  load average: 2.87, 3.81, 4.78
Tasks: 158 total,   2 running, 155 sleeping,   1 stopped,   0 zombie
Cpu(s): 28.8% us,  8.3% sy,  0.3% ni, 50.7% id,  4.6% wa,  1.0% hi,  6.3% si
Mem:   1036752k total,   684076k used,   352676k free,     4524k buffers
Swap:  3028244k total,  1259400k used,  1768844k free,   134752k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23481 rich      15   0  158m  80m 6812 S  9.6  8.0 153:04.12 amule
21549 rich      16   0 32548 8072 6140 S  7.6  0.8 882:03.19 ksysguard
 6859 gkrellmd  15   0 11768  888  716 S  6.6  0.1   2081:23 gkrellmd
 7520 rich      16   0  104m  10m 6352 S  6.0  1.0 189:31.68 kicker
 7271 root      15   0  540m  80m 3112 S  5.6  8.0   1723:03 Xorg
25683 rich      15   0  304m  43m  37m S  4.0  4.3 621:40.59 qemu
 7534 rich      17   0 29100 5772 4936 S  1.7  0.6  21:42.72 kdf
21556 rich      15   0  3052  884  708 S  1.0  0.1 134:32.27 ksysguardd
31635 rich      15   0 45604 8124 3280 S  0.7  0.8   1:29.10 btdownloadgui
 7810 rich      15   0 58644 1812 1548 S  0.3  0.2  28:48.73 xmms
 6514 rich      16   1  262m 114m  12m S  0.3 11.3 153:27.03 firefox-bin
 8545 rich      15   0 26720 2588 2520 S  0.3  0.2  16:36.00 gksu
 8294 rich      15   0  174m 8648 7768 S  0.3  0.8   5:09.21 kaffeine

After closing almost every other software, one hour after having closed Mozilla:

top - 20:03:46 up 17 days, 18:56,  1 user,  load average: 0.60, 1.94, 2.78
Tasks: 104 total,   1 running, 103 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.3% us,  1.3% sy,  0.0% ni, 86.3% id,  0.0% wa,  0.0% hi,  1.0% si
Mem:   1036752k total,   983776k used,    52976k free,    42988k buffers
Swap:  3028244k total,   653616k used,  2374628k free,   558504k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21549 rich      16   0 32548 8832 6720 S  7.6  0.9 892:58.52 ksysguard
 7271 root      15   0  453m 211m 2404 S  2.7 20.9   1729:14 Xorg
21556 rich      16   0  3052  884  708 S  1.7  0.1 136:11.99 ksysguardd
 6859 gkrellmd  15   0 11768  892  720 S  1.0  0.1   2087:02 gkrellmd
 7532 rich      15   0 35504 8464 6096 S  0.3  0.8   0:17.54 konsole
14372 rich      16   0  2264 1132  840 R  0.3  0.1   0:00.03 top
    1 root      16   0  1956  508  476 S  0.0  0.0   0:03.69 init


After a reboot (same software as at last top):

top - 20:16:16 up 9 min,  1 user,  load average: 0.32, 0.31, 0.16
Tasks:  98 total,   2 running,  96 sleeping,   0 stopped,   0 zombie
Cpu(s):  6.6% us,  0.3% sy,  0.0% ni, 91.4% id,  0.0% wa,  0.0% hi,  1.7% si
Mem:   1036752k total,   302252k used,   734500k free,    15596k buffers
Swap:  3028244k total,        0k used,  3028244k free,   161340k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7630 rich      16   0 32312  17m  12m S  3.7  1.7   0:07.50 ksysguard
 7318 root      15   0 53648  15m 3628 S  2.3  1.5   0:11.30 Xorg
 6883 gkrellmd  15   0 10740 1144  852 S  1.3  0.1   0:09.12 gkrellmd
 7639 rich      15   0  2924 1460  924 S  0.3  0.1   0:00.94 ksysguardd
 7684 rich      16   0 34712  15m  11m R  0.3  1.6   0:00.49 konsole
    1 root      16   0  1956  656  560 S  0.0  0.1   0:01.03 init

Xorg goes from 453m 211m to 53m 15m. Can you do something about that? Please!

Welcome to Unix.   In general, memory that is freed by an application like Xorg
is returned to the free list for that application, but the application size does 
not shrink.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

I guess this report covers my problem:
https://bugzilla.novell.com/show_bug.cgi?id=434561

However from what I see everybody complains about "after hours/days of working" when my problem is quite simpler -- with low memory (because there is little RAM or there is plenty of it but a lot of apps are already running) just after launching new app X server crashes/restarts. This of course means that all apps running in X are also crashed.

My only guess is the app asks X to get handle to new window and... at this point is confusing:
a) if X is too gullible and tries to allocate memory, it does not get it and operates on it -- ok, X bug, it is fair to kill X
b) if there was memory allocated, and then the app allocates some more (but for internal purposes) why X is killed -- this app should be killed, right?

Anyway, it would be good to create a error dialog about not allocated memory just after starting X, and if any app is requesting memory in low-mem conditions, the allocation should be refused and the error dialog should be shown (this is because it is not sure if the app can handle it, it may crash as well -- so there is at least some info for the user).

In other words my point is -- if some app within X misbehaves it and only it should be killed, not X with all apps running. This disturbs me most because bugs will haunt us for long, so memory, no-memory, but no matter what X should be protected from not its faults.

Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.