Date: Fri, 15 Dec 1995 07:18:56 EDT From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: hackers@freefall.FreeBSD.org Subject: Re: growing X server processes Message-ID: <199512151218.MAA09375@exalt.x.org> In-Reply-To: Your message of Fri, 15 Dec 1995 10:15:21 EDT. <199512150915.KAA00742@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512151218.MAA09375>