On Wed, 22 Oct 2003, Dermot McGahon wrote: >> It is definitely supported. I can say that with extremely high degree of confidence because I am the Red Hat XFree86 maintainer, and have been for 3 years. So I very much know what hardware is supported, and have tested it and use it daily personally. > >Mike, 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. [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. >Myself and others have had our machines badly swapping with very >limited setups. Bootup, log in, window manager & desktop. >Swapping occurs. This is with 128MB ram. 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. >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. 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 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. >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.. 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. Hope this helps. -- Mike A. Harris _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
