Date: Sat, 16 Dec 1995 18:28:40 EDT From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: hackers@freefall.FreeBSD.org Subject: Re: growing X server processes Message-ID: <199512162328.XAA12952@exalt.x.org> In-Reply-To: Your message of Fri, 15 Dec 1995 13:37:05 EDT. <6990.819031025@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I use it for everything. Without gnumalloc my server would easily
> > grow to ~10meg and never shrink. This was not very good on my 8meg ram/
> > 32meg swap machine to have a third of my swap consumed by unused server
> >
> You should try out the malloc in -current then. I would probably do even
> better than gnumalloc in low-ram environments.
>
Unfortunately it doesn't. Using gnumalloc my X server "idles" at ~3meg
virtual size. Using the malloc in -current it idles at ~4meg virtual size.
In fact a call to free with the -current malloc can actually result in
the process virtual size growing larger!!!
Consider the following trivial test program. (The read/write calls are
just markers to unambiguously tag lines in the source to the kdump output.):
#include <stdlib.h>
int main ()
{
void* ptr;
(void) read (0, NULL, 0);
ptr = malloc (4000000);
(void) write (1, NULL, 0);
(void) free (ptr);
(void) write (2, NULL, 0);
return 0;
}
Here's the relevant exerpt of the the ktrace using the -current malloc:
...
17898 t CALL read(0,0,0)
17898 t RET read 0
17898 t CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0)
17898 t RET mmap 134316032/0x8018000
17898 t CALL break(0x2104)
17898 t RET break 0
17898 t CALL break(0x2104)
17898 t RET break 0
17898 t CALL break(0x3d4000)
17898 t RET break 0
17898 t CALL write(0x1,0,0)
17898 t RET write 0
17898 t CALL break(0x3d4000)
17898 t RET break 0
17898 t CALL break(0x3d5000) <<== it got bigger in the call to free!!!
17898 t RET break 0
17898 t CALL write(0x2,0,0)
17898 t RET write 0
17898 t CALL exit(0)
The reason for this, I found by examining the code, is that -current's
free calls malloc and destroys any chance of returning the pages to the
OS!!!
For comparison here's the ktrace using gnumalloc:
...
17996 t CALL read(0,0,0)
17996 t RET read 0
17996 t CALL break(0x5104)
17996 t RET break 0
17996 t CALL break(0x6000)
17996 t RET break 0
17996 t CALL break(0x3d7000)
17996 t RET break 0
17996 t CALL write(0x1,0,0)
17996 t RET write 0
17996 t CALL break(0x3d7000)
17996 t RET break 0
17996 t CALL break(0x6000)
17996 t RET break 0
17996 t CALL write(0x2,0,0)
17996 t RET write 0
17996 t CALL exit(0)
So you can see that gnumalloc does much better in this case, even if it
is a somewhat contrived test. But I'm not so sure that it's so contrived;
because my guess is that this is probably what accounts for my X server
idling with a one megabyte larger process virtual size using -current's
malloc that with gnumalloc.
--
Kaleb KEITHLEY
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512162328.XAA12952>