From owner-freebsd-arch Wed Feb 27 20:59:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by hub.freebsd.org (Postfix) with ESMTP id 349E237B400 for ; Wed, 27 Feb 2002 20:59:34 -0800 (PST) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g1S4xXP99330 for ; Wed, 27 Feb 2002 23:59:33 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Wed, 27 Feb 2002 23:59:33 -0500 (EST) From: Jeff Roberson To: arch@freebsd.org Subject: Slab allocator update Message-ID: <20020227234433.Y59764-100000@mail.chesapeake.net> 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 I have updated UMA. It's available at http://www.chesapeake.net/~jroberson/uma.tar This fixes uma on x86, which was definately broken. Thanks go to phk for helping me debug this. This also fixes a few lock order reversals, and my bad use of cpuid in zalloc_internal. I have one more lock order reversal to fix that occurs some times when zones are drained. This patch has been tested on SMP alpha and a single proc x86. If you intend to test this patch on a SMP box with greater than 2 cpus please adjust maxcpu in uma_core.c There is a big XXX next to this that explains why. I'd like to summarize the input that I have received so far: 1) Some folks disagree with the per cpu lock, but that can be worked on later. 2) malloc_type Statistics should reflect what is feasible with this allocator design, and some stats don't always have to be completely acurate. 3) No real concensus on name space issues yet. 4) What I have so far is workable, incorporating other objects into uma is somewhat questionable. (mbufs and pbufs anyone?) If anyone disagrees with the statements above please let me know. My plans going forward are: 1) Fix the last lock order reversal. 2) Fixup the statistics for uma and malloc. 3) Convince people to test it. 4) Commit. 5) Work on converting everything to uma_* interfaces, and adding initializers. 6) nap Does anyone see any work items that I missed? I'd like the road to commit to be well defined so it actually happens. Otherwise I think I'll be maintaining patch sets forever. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message