Subject: Re: further vm adventures
To: Sean Witham <Sean.Witham@asa.co.uk>
From: None <jiho@postal.c-zone.net>
List: tech-kern
Date: 05/03/1998 21:36:09
On 01-May-98 Sean Witham wrote:

>> 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.)
>
> I call that a design flaw which introcuces a tempory leak *8-) How 
> tempory depends on circumstances, in  this case how long before
> you restart the xserver. This is in away almost worse than a normal
> leak. A normal leak is a code bug that can be tracked and corrected, a
> design flaw may not be so easy to fix/find.

A "design flaw" or a "feature", depending on your goals.

This one was VERY hard to figure out, but isn't particulary hard to fix once
you understand it.  Or at least, not for the most common case, which is an
anonymous allocation that has never been forked or swapped.

The swapped case seems completely fixable, but I think that requires the
pilfering of a swap pager function from FreeBSD, which NetBSD seems to lack
(either that or I didn't understand it).

As for the forked case, anything already allocated at fork time gets converted
to copy-on-write.  Once the child execs or exits, I suppose just an object
collapse would make things manageable with respect to this problem.  This seems
like it might potentially raise more questions that the swapped case, though. 
But this is another argument for the shared vmspace vfork.

Mapped files are probably best left alone; consider it a form of caching.

Anyway, this is really a problem for FreeBSD, where fixing the Mach vm is a way
of life.  NetBSD is moving to UVM, which was designed with problems like this in
mind, according to Chuck.

With NetBSD 1.2, I independently arrived at a patch that is very similar to what
FreeBSD will have, except mine is more primitive and still ignores the forked
and swapped cases.  It works fine with X now, though (something else I did
earlier was tripping the X server up, not this patch), and does fix the problem
with X very handily.  I've even turned backing store on!  Much better!

Now, if you want to quibble with a design, how about X...?


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


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 03-May-98
Time: 21:36:09

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