From owner-freebsd-current Fri Sep 22 06:18:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA29661 for current-outgoing; Fri, 22 Sep 1995 06:18:11 -0700 Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA29655 ; Fri, 22 Sep 1995 06:18:07 -0700 Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id GAA04416; Fri, 22 Sep 1995 06:15:54 -0700 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: asami@cs.berkeley.edu (Satoshi Asami) cc: nate@rocky.sri.MT.net, roberto@keltia.Freenix.FR, freebsd-current@FreeBSD.org, rich@FreeBSD.org Subject: Re: XFree86 and the new malloc In-reply-to: Your message of "Fri, 22 Sep 1995 05:49:03 PDT." <199509221249.FAA27600@silvia.HIP.Berkeley.EDU> Date: Fri, 22 Sep 1995 06:15:48 -0700 Message-ID: <4412.811775748@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org Precedence: bulk > We'll have to test how phkmalloc works, and see what we should > recommend them for 3.1.3 (or 3.2?). I'm going to compile the X server > with phkmalloc tomorrow (I'm doing a make world now) and let you guys > know if something goes "puff" or "bloat". Just for the record: I'm VERY interested in numbers and data, but I'm also very interested in the subjective "how does it feel" reports, since that one number we really want isn't that easy to find: "current working set size in pages". The only semi-reliable way we have to measure this is on the paging- rate, not the amount paged, but the number of pages/sec or something. (This is, by a staggering coincidence, also why the app feels slow :-) If you run something with phkmalloc sufficiently long that you think it won't blow up on you, try #undef'ing EXTRA_SANITY and possibly SANITY as well in phkmalloc, and try again, that should give even better speed, at the expense of sanity-checks. EXTRA_SANITY is rather expensive, but checks for a lot of internal inconsistencies in phkmalloc, I expect that to be removed after a sufficient amount of testing has been done. SANITY checks the sanity of how the application calls phkmalloc. I expect this to be a standard compile option, since the results of leaving it out in a program which screws up is very confusing. I have a couple of ideas which could make phkmalloc better at freeing memory back to the OS (as opposed to just not accessing it) but I will not touch it for another couple of weeks I expect, and it will need a pretty tough bashing on my own boxes first before it gets committed. I will be most grateful if somebody will do a full-scale code-review too. Your testing is most appreciated... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes to far... (Poul Henningsen)