From owner-freebsd-hackers Sat Jun 24 07:39:14 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA10225 for hackers-outgoing; Sat, 24 Jun 1995 07:39:14 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA10219 for ; Sat, 24 Jun 1995 07:39:11 -0700 Received: from id.slip.bcm.tmc.edu (hou31.onramp.net [199.1.137.159]) by who.cdrom.com (8.6.11/8.6.9) with ESMTP id HAA05400 for ; Sat, 24 Jun 1995 07:38:58 -0700 Received: by id.slip.bcm.tmc.edu (8.6.11/1.34) id JAA03296; Sat, 24 Jun 1995 09:33:37 -0500 Date: Sat, 24 Jun 1995 09:33:37 -0500 From: rich@id.slip.bcm.tmc.edu (Rich Murphey) Message-Id: <199506241433.JAA03296@id.slip.bcm.tmc.edu> To: roberto@blaise.ibp.fr CC: henrich@crh.cl.msu.edu, freebsd-hackers@freebsd.org In-reply-to: <199506230854.KAA06398@blaise.ibp.fr> (roberto@blaise.ibp.fr) Subject: Re: Memory leak somewhere? Reply-to: rich@lamprey.utmb.edu Sender: hackers-owner@freebsd.org Precedence: bulk |From: roberto@blaise.ibp.fr (Ollivier Robert) | |> suggests perhaps there is a problem with something somewhere in FreeBSD. This |> behaviour seems to be new with the 0412-SNAP, although I dont have any |> proof of this. This is crazy, I have a 32mb machine, and its performing like |> a dog because of this sort of memory usage (!) :(. On a 16mb machine, if you |> run any significant apps you go to swaphell because of the memory usage here. |> Could this be a leak in the kernel malloc, or mmap code or some such? | |Relink the server with either -lgnumalloc or -ldlmalloc (found in |ports/devel/libdlmalloc). The libc's malloc take as much as two times the |memory needed per allocation. | |I think we should throw away the libc's malloc and adopt another one. |-- |Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG |FreeBSD keltia 2.0-BUILT-19950503 #3: Wed May 3 19:53:04 MET DST 1995 We tried using gnumalloc for XFree86 between 3.0 and 3.1 but beta testers reported problems with the X servers, so we switched back to the one in libc. The malloc in libc is by far the most stable of the lot. I don't know that anything has changed in gnumalloc. Rich