Please make your lines shorter, as they scroll off the right hand side of the screen and are very very long. It's hard to read your emails. I suggest making your right margin at the standard column 72, for easier reading.
Apologies.
[SNIP]In my own case, the display adapter is the Intel 845G. In bios, this is set to use 8MB system ram I thought. In the XF86Config it is set to use 10MB, I don't know if this is vram or dram. lspci -v reports a block of memory of 128MB for this device. Is this onboard vram do you know? pmap of the X process shows a 128MB chunk of shared memory. Maybe this is the vram?
Intel video hardware does not have dedicated video memory, it steals memory from your regular system memory. You configure how much it steals from inside your BIOSs CMOS settings menu. If your BIOS doesn't have that available as a changeable option, you can use the VideoRAM setting in the XFree86 config file and it will work with some Intel hardware, but might not work with all Intel hardware.
Ok, thank you. This is informative.
[-]
With 128Mb of RAM, your system barely meets minimum system requirements for a graphical desktop. I would expect swapping to occur, yes. Especially since your graphics hardware uses your system memory, so that memory is not available for your system to use.
Fair enough. 128Mb RAM is not enough for modern desktops with anti-aliased fonts. This started happening after a Suse 8.0 to Redhat 9 upgrade. I presume there were eye candy improvements made over the last year or two and most probably accounts for the swapping.
I've gone to runlevel 3 and just started X on its own, and X and twm. Similar large process size reported by ps.
The memory size of the X server reported by "ps" and/or "top" is very useless. It includes mmap'd video memory and I/O regions and other details which do not amount to the X server using real memory generally, however most people misinterpret it to do so and think the X server is "bloated" or some other crackrock.
Well, if the bios setting is being adhered to, then an X server started with no applications at all; no window manager; no pixmaps, is still being reported by ps as 150Mb. Only 10Mb of this is accounted for by display adapter ram borrowing.
In the case of your particular system, the video adaptor is using system memory for itself as that is how it is designed to begin with, so the video memory does actually end up being memory your system cant ever use for anything else, but that's a coincidence as far as top/ps is concerned.
To determine the REAL amount of memory being used by the X server, one has to analyze the contents of /proc/#(pidof X)/maps as root, as that gives the complete VMA breakdown. Of course one has to understand what the various fields actually mean in order to make heads or tails of the numbers, but that can be determined by reading the kernel source code that provides the proc maps files, as it has enough comments in it to be useful to interpret the data.
I suspect this is what the pmap command does, but if not I'll start a new learning exercise. I'm attaching the pmap output to this email.
I don't understand that much about X, but one thing I was wondering is how a large X process size would interact with the kernel VM system. Does it have the capacity to cause swapping like we were seeing?
The X process itself consumes extremely little memory. It is X applications themselves which consume memory and X resources. In particular applications which use heavy use of graphics images, will inflate the size of the X server process, because X pixmaps are an X resource and are stored *inside* the X server. If you view a webpage with 100Mb of graphic images in Mozilla for example, your X server will increase by 100Mb in size as those images are stored in the X server.
This is true, and another member of the same LUG is seeing exmh leaking X resources, but in my case ps reports 150Mb under the size column even when no (zero) applications are running.
And with respect, this doesn't answer my question about interaction with the kernel VM code, although I should probably ask on the lkml about that.
Many other people in the LUG and in the office have small process sizes for X and have no problems whatsoever. And since I bought more ram, I don't have a problem either with my desktop, but have seen large process sizes on other machines which we are putting a product on and deploying. One of these has an nvidia gforce4 MX440 so this doesn't seem to be just a graphics card ram issue.
In general, if you see your X server using a lot of memory (loosely defined by subtracting the amount of video memory and MMIO regions from the ps/top amount of memory in use) you most likely have applications which are leaking X resources. If you kill those applications the X resources will be freed up. However you have to determine which applications are leaking resources to begin with. In these cases, it is an application bug causing X server memory usage to inflate. This is similar in nature to an application which memory leaks. When an application leaks memory, as far as the kernel understands/knows, you have an application which keeps asking for more and more memory, and so the kernel will give it more and more memory. The total memory used in the system will increase, and the kernel is not in any way at fault. Likewise, if Mozilla, gnome-panel, or some cutesy pie panel-applet or somesuch uses 400Mb of memory to store pretty pictures, your X server will say "sure, I can hold that for you" and will increase 400Mb in size.
It has been ages since I've seen someone report a bug like this that actually turned out to be an X server memory leak, so while it is certainly theoretically possible that there is a memory leak, it is much more likely you have buggy applications leaking pixmaps or other resources. With 128Mb of total system memory, and your video hardware configured to use 10Mb of that, that leaves only 118Mb of memory for the system to use. That is not very much at all on a modern Linux/X11 desktop running GNOME or KDE with antialiased fonts, etc..
The anti-aliased fonts explain the swapping I think.
This only leaves me with an accounting figure that is larger than it should be but there is probably a rational explanation for it, and I've taken up enough of your time. I've installed more RAM, and I really don't think that X is leaking anything, was just curious about what contributed to a 150Mb accounting figure.
If you run such low memory systems, you really should consider disabling various things to minimize resource usage, or switching to alternative desktop setups with openbox/fluxbox/blackbox/or some other window manager, and use smaller applications. Mozilla, OpenOffice, Nautilus, and other GNOME/KDE major applications are very resource hungry, and will consume a lot of memory in your system - some of that via the X server.
Well, in fact we won't even have video cards never mind desktops in these servers, unless we install them just for 3D rendering purposes.
We're using them to render video, grab the frames from the X server, MPEG encode, and stream over IP. I'm just trying to make sure we're not wasting RAM. I did however have some desktop problems but they are not my main concern.
Hope this helps.
It does. You've been very helpful and thank you for your time. Some day, I will learn how to use a mailer properly.
Dermot. --
Attachment:
pmap.out
Description: Binary data
