simon@corona.att.com (02/06/90)
Environment ->
Hardware :
4/60 24 Meg ram w cgsix - diskless served by 4/260 w 48 Meg swap allocation
Software :
Running X11R4, developing Xt / Openlook based graphics interfaces
typical application:
size:
text data bss dec hex bss + data at run time
540672 106496 0 647168 9e000 328 K
ldd: (shared libaries being bound to)
-lX11.4 => /usr/lib/libX11.so.4.2
-lXmu.4 => /usr/lib/libXmu.so.4.0
-lc.1 => /usr/lib/libc.so.1.3
I am noticing strange things on the sparkstation 1's we are developing on.
After a reboot vmstat reports a significant amount of free memory - 17896K
on 24 Meg system. After starting X11R4 development environment (2 xterms,
wm, xload) we are down to 12492K. After first make and application
execution 6196K. Free memory dropped most precipitously during the link
edit (executible file size ~ 2 Meg). After second make and application
execution 6296K. After third make of different version in different
directory and execution 5020K. Where has 7Meg of free memory gone ??? No
shared memory is being used. I can only think of the following
possibilities:
Used pages are not immediately freed upon process death.
Text pages are not considered free until memory pressure occurs.
Disk blocks are being locally cached in physical mem even when using NFS.
When multiple compiles and executions are done free memory monotonically
goes to between 256 and 1024K and paging activity increases. Incidently
all measurements where made when free memory was no longer changing.
Has anyone out there noticed this behavior ? I suspect other UNIX boxes do
not exhibit the same behavior. Of particular frustration to me is the
inability to get detailed system stats as to the # of vm segments active,
their virtual size, resident set size, disk buffering behavior (pmem used
by buffer ) etc. I called the SUN info line but this question seemed to
be out of their league.
Marc Simon
ATT Bell Labs
simon@corona.ATT.COM 201-615-2535simon@corona.att.com (02/14/90)
Feedback from my previous posting has yielded the following tidbits:
Disk blocks (either direct I/O or over NFS) are cached in physical memory
in SUNOS 4.0.3. Physical memory pages consumed by disk buffering are NOT
considered to be free by vmstat. The text pages of processes are cached in
physical memory and reclaimed where possible - something which is true in
4.3 BSD as well. Physical memory consumed by text page buffering is NOT
considered free by vmstat.
I verified disk buffering behavior experimentally on an idle system:
rebooted 24M system -> Large amount of memory shown to be free by vmstat
dd'd small file to /dev/null -> forced text pages of "dd" to be loaded
ran vmstat to determine free physical memory.
dd'd unreferenced version of vmunix to /dev/null
ran vmstat again. (Excess physical memory still reported - no page outs )
The difference was 760K or 778240 bytes. The size of the file was 789309.
Since the only memory draw-down could be due to disk buffering action, the
test implies that all disk i.o. pages are buffered in physical memory when
possible. In addition, one can cause program pages to be freed and/or
paged out by reading / writing large files concurrently. This suggests
that disk buffering competes on a similar footing as other virtual memory
operations for physical memory.
Other UNIX boxes partition the demands of disk buffering into a reserved
chunk of physical memory. My suspicion is that there are both benefits and
drawbacks to the approach SUN has taken of allowing flexible allocations
of physical memory to disk buffering and program paging.
I have yet to make any tests to see how data pages are returned to the
free list after process death. It is widely acknowleged the vmstat is
deficent in reporting virtual memory consumption (active virtual memory).
What prompted my original posting was a suspicion that the virtual memory
subsystem of SUNOS 4.0.3 on the sparcstation was not performing as
optimally as it could. I would appreciate hearing from anyone who is
familiar with the innards of the SUN kernel and its design trade offs.
Marc Simon ATT Bell Labs
simon@corona.ATT.COM 201-615-2535