From owner-freebsd-hackers Sat Dec 16 15:29:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA09954 for hackers-outgoing; Sat, 16 Dec 1995 15:29:19 -0800 (PST) Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA09945 for ; Sat, 16 Dec 1995 15:29:14 -0800 (PST) Received: from exalt.x.org by expo.x.org id AA15411; Sat, 16 Dec 95 18:28:43 -0500 Received: from localhost by exalt.x.org id XAA12952; Sat, 16 Dec 1995 23:28:41 GMT Message-Id: <199512162328.XAA12952@exalt.x.org> To: hackers@freefall.FreeBSD.org Subject: Re: growing X server processes In-Reply-To: Your message of Fri, 15 Dec 1995 13:37:05 EDT. <6990.819031025@critter.tfs.com> Organization: X Consortium Date: Sat, 16 Dec 1995 18:28:40 EDT From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > 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 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