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>