From owner-freebsd-arch Mon Apr 8 1:41:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2A61B37B405 for ; Mon, 8 Apr 2002 01:41:07 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id D8D555309; Mon, 8 Apr 2002 10:41:04 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Jeff Roberson Cc: arch@freebsd.org Subject: Re: Removing limits from malloc(9) References: <20020408041726.U53877-100000@mail.chesapeake.net> From: Dag-Erling Smorgrav Date: 08 Apr 2002 10:41:04 +0200 In-Reply-To: <20020408041726.U53877-100000@mail.chesapeake.net> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jeff Roberson writes: > The last bit that is missing before we can call malloc/free w/o Giant is > the malloc_type statistics. Currently there is nothing really protecting > them. There really is no lock that they can conveniently live under. I > have a few options. The one that I'm leaning towards is only enabling > malloc_type statistics if INVARIANTS is compiled in. Then I could make > one lock per malloc_type. The reason this shouldn't be the default is > because it creates a single point of contention which is in sharp contrast > with the rest of the allocator. It's still a lot better than Giant, and it's a leaf lock so there shouldn't be any worries about reversal. I'd go for it if I were you. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message