The original posting was as follows:
> Our Sun Ultra 2 Creator (Solaris 2.5, SunOS 5.5, kernel patches level
> 9) has a problem on opening X windows.
>
> Immediately on startup, for ANY user, for ANY window manager, for ANY
> graphics mode, the executable /usr/openwin/bin/Xsun grabs over 100 Meg
> of RAM. This is even before any applications have been opened. This
> figure does still increase when you open new applications, and has
> been known to reach over 200 Meg !!! (The culprit logged out as soon
> as he could...)
>
> I've tried everything I can think of, and sunsolve doesn't appear to
> have any appropriate information available. Does anyone have any
> ideas?
Thanks to:
Krassimir Todorov
Vaughn Adams
Andy McCammont and
Tomasz M. Wolniewicz
who have replied so far.
In fact there was no problem at all. There was no problem due to the
large screen size and colour depth. Even at 32 bit colour at
1280x1024 we only require 5MB to map the screen. In fact there was no
problem at all, as the following excerpt from the Solaris 2 FAQ states
(Thanks Krassimir):
5.48) Why is Xsun such a memory pig, especially on the SX, S24 and FFB?
Ps counts the mappings for the framebuffer as memory.
Especially on the FFB where a number of different mappings
of the device address space is used to optimize
access this can cause large amounts of memory, but not
physical memory, to be mapped and shown by ps.
It's not unusual for the FFB+ (Creator3D) to show a 500MB
process size for the X server.
Solaris 2.3 FCS also has a number of Xsun memory leaks when using
the SX. Get the SX patches or upgrade to 2.4.
To test this I wrote a small program to malloc memory in 1MB chunks
until there was none left, and report the amount of memory
successfully allocated. I ran this immediately before and after
starting openwin. The result was a deficit of only 6MB after Xsun was
running. So ps was lying. The following entry from the 'Symptoms and
Resolutions' section of the sunsolve database helps:
-----------------------------------------------------------------
SRDB ID: 11507
SYNOPSIS: Xsun server process appears very large on SX or TCX
DETAIL DESCRIPTION:
The "ps" command shows the Xsun server process to be very large
on some systems.
This is particularly noticeable on:
* SX graphics systems : eg SS10 SX, SS20 SX
* SS5 with 24 bit A24 framebuffer
* SS4
The latter two share a common device driver (tcx).
Users may think that they are seeing performance degradation,
and consider the problem a bug.
SOLUTION SUMMARY:
In most cases there is NOT a problem.
What is happening is that
"ps" is showing the sum of the mapped
parts of the process's address space, and this does not have
to correspond to either real memory, or to allocated swap space.
That is what "ps" does - it tells you about a particular process.
Access to many devices is often memory-mapped into the address
space of a process. This is a common technique, and means that
applications need not know the details of the device, instead they
just do whatthey consider to be regular memory writes.
A process has a virtual address space, and cannot write into "real"
memory at all - instead the kernel intercepts all such requests
and handles them together with the MMU.
The sx and tcx drivers use a particularly large amount of the process
address space.
We can demonstrate that the amount of swap allocated is not as much
as one might expect from looking at the ps output:
1. Exit all but one command tool, and do a "Save Workspace", so that when
you restart OpenWindows, only that one tool is started.
2. Exit OpenWindows.
3. Execute "swap -s" to see how much swap space is currently free.
4. Restart OpenWindows.
5. In your command tool execute "swap -s" again, and compare the amounts
free. This will probably indicate about 8-12 Mb used. Remember that olwm,
cmdtool, ttsession, xinit and other processes have also contributed to
this usage.
6. Execute "ps" and you will see that the Xserver process alone is
reported as much larger than that (Note: /usr/bin/ps reports its size
in 4k pages on Solaris Sparc systems).
This phenonmenon is not new, nor specific to these framebuffers. The
cgsix, the mouse, the keyboard, are all mapped in the same way, but the
amount of address spacemapped for these devices is smaller so less
noticeable.
One footnote: the SX and A24 are 24-bit devices, and if you run OpenWindows
in 24 bit mode, then they WILL use more swap than in 8 bit mode. In such
circumstances you may see unavoidable paging until you add more memory to
compensate for your increased demands.
PRODUCT AREA: Windows
PRODUCT: OpenWindows
SUNOS RELEASE: Solaris 2.4
HARDWARE: Sun 4m
-----------------------------------------------------------------
-- | Chris Murphy: Aston Space Geodesy, | | Civil Engineering, The University of Aston, Birmingham B4 7ET, UK | | TEL : +44 121 359 3611 ext 4552 FAX : +44 121 333 3389 | | MAIL: murphycm@aston.ac.uk URL: http://www.aston.ac.uk/~murphycm/ |
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:46 CDT