On 29-Apr-98 Sean Witham wrote:

>> >>> Did you try what I suggested (exit the X server and see if the "leaked"
>> >>> memory has been recovered)?
>> 
>> Yes, exiting the server recovers the memory, but that doesn't explain it. 
>> The memory was never found to be in the server's vm space to begin with,
>> as I tried to make clear.
>> 
>> It only shows (as I've said all along) that the memory has SOMETHING to do
>> with the X session in general, even though it cannot be associated with
>> ANY program.
>> 
>
> I might be showing my ignorance here but if memory is reclaimed after
> the exit of a process such as the xserver sureley the lost memeory is
> attricuted to that process ? Under what cirumstances can the exit of a
> userland process release memeory leaked by the kernel ? If the memory
> is being relased by the kenerl rather than the xserevr is it a
> memory leak or is there a method for a process to reserve mememory
> such that is not attricuted to a process by the VM stats and yet
> still free'ed up when the process exists. Would shared memory do this?

You worry about YOUR ignorance in a discussion with ME?!?

But this is a fascinating point.  It seems not to involve 'shared memory' as you
mean it, but to involve the way the Mach vm handles things in general to make
sharing possible.

I say "seems" because -- while others with better expertise than mine say this
is true, and looking at ddb output and the kernel source makes it appear almost
certain -- I have not yet proven it myself absolutely.

And whether you call this a "leak" or not is a matter of semantical opinion.  I
do, others may not.

The Mach vm appears to be leaking pages in memory objects, backing map entries
for ordinary allocations made by the X server.

The pages are leaked when the X server does a realloc that reduces the size
of an allocation.  In such cases, realloc functions may optimize by dropping
memory off the end of the existing allocation, rather than doing a full blown 
allocate-copy-deallocate cycle.  When presented with the request to drop memory
off the end, the Mach vm substitutes a truncated map entry, but instead of
pruning the pages in the memory object to match the truncated map entry, it
leaves all of the existing pages there in case any other mapping might want
them.  (None ever will, but the Mach vm doesn't try to know that.)

The net result is that 'ps' shows the X server with only the reduced allocation,
while 'systat vmstat' shows all of the pages from the original allocation still
on the active list.

However, since the X server's map entry has the only reference on the memory
object, when the server exits that object is deallocated and all of the pages
are freed.


--Jim Howard  <jiho@mail.c-zone.net>


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 29-Apr-98
Time: 14:50:00

This message was sent by XFMail
----------------------------------