From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 15:25:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FD6437B401; Thu, 10 Apr 2003 15:25:41 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAB4943F75; Thu, 10 Apr 2003 15:25:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0274.cvx40-bradley.dialup.earthlink.net ([216.244.43.19] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 193kU8-00069E-00; Thu, 10 Apr 2003 15:25:32 -0700 Message-ID: <3E95EEAC.AE812757@mindspring.com> Date: Thu, 10 Apr 2003 15:22:36 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Petri Helenius References: <3E94A22D.174321F0@lbl.gov> <3E94A8C4.3A196E42@lbl.gov> <05b601c2ffa2$ed87a5b0$932a40c1@PHE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4c964df480dfbc21cc9b441a64eb8e474667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: "Jin Guojun \[DSD\]" Subject: Re: tcp_output starving -- is due to mbuf get delay? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2003 22:25:41 -0000 Petri Helenius wrote: > There was a discussion on mballoc performance on freebsd-net about a month ago > but it has since died without conclusion. Actually, a researcher at UKY implemented an alternate allocator using an explicit freelist and mp_machdep.c tricks, rather than using the zone/slab/uma stuff, and obtained a significant speedup. Yes, I was involved in suggesting implementation details. The resulting code is not SMP-safe, however, unless you are willing to use a global freelist (obviously). BTW: The zone allocator *still* calcualtes some values each time it goes back to the system for more pages, that it should precalculate and cache instead. -- Terry