From owner-freebsd-hackers Fri Dec 15 04:19:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA18112 for hackers-outgoing; Fri, 15 Dec 1995 04:19:37 -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 EAA18107 for ; Fri, 15 Dec 1995 04:19:33 -0800 (PST) Received: from exalt.x.org by expo.x.org id AA12003; Fri, 15 Dec 95 07:18:58 -0500 Received: from localhost by exalt.x.org id MAA09375; Fri, 15 Dec 1995 12:18:57 GMT Message-Id: <199512151218.MAA09375@exalt.x.org> To: hackers@freefall.FreeBSD.org Subject: Re: growing X server processes In-Reply-To: Your message of Fri, 15 Dec 1995 10:15:21 EDT. <199512150915.KAA00742@uriah.heep.sax.de> Organization: X Consortium Date: Fri, 15 Dec 1995 07:18:56 EDT From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > As Wilko Bulte wrote: > > > > Probably a FAQ but: why is XF_S3 so much more memory hungry then > > XF_SVGA? I used an old ET4000 before and it did not grow nearly as > > much as the S3 I use now./ > > > > There has also been much debate about using gnumalloc. Was that just for > > building the clients and/or for the server? > > Mainly for the server. 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 heap. With gnumalloc the server may peak around ~10 but when memory resources are freed gnumalloc actually returns the memory to the system with brk, so my server typically runs at about ~2.5-3meg. I get similar improvements by using gnumalloc in memory hungry clients like Mosaic and xv. The key is that gnumalloc calls sbrk with negative values to shrink the process virtual size when pages in the malloc arena become unused (by calls to free). I hope phkmalloc does the same. Of course this can fail if the heap becomes fragmented, but the empirical evidence so far seems to indicate that this is not a problem. The other thing gnumalloc has is a MacOS-style relocating memory allocator, which allows for garbage collection and thus eliminates the heap fragmentation problem, but it's awfully hard to retrofit this kind of allocator into legacy applications like the X server. > ... and XFree86 is moving towards > their own malloc for the server (it's already in the latest beta, and > it seems to work fine). It's not really "their own malloc". What it is is their own Xalloc. By default the server in the X Consortium sample implementation just uses malloc for Xalloc, but XFree86 have added value to their product by providing a better allocation strategy. They've profiled memory usage patterns in the server and written their Xalloc implementation using what they learned from the profile; but it's not "their own malloc". (For one thing the function call signature isn't the same as malloc.) -- Kaleb KEITHLEY