From owner-freebsd-arch Sun Feb 16 22:41:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C38D137B401 for ; Sun, 16 Feb 2003 22:41:35 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E42043F3F for ; Sun, 16 Feb 2003 22:41:34 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.5/8.12.5) with ESMTP id h1H6fVLZ063366; Mon, 17 Feb 2003 17:41:32 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.6/8.12.5/Submit) id h1H6fUrJ063365; Mon, 17 Feb 2003 17:41:30 +1100 (EST) Date: Mon, 17 Feb 2003 17:41:30 +1100 From: Peter Jeremy To: Bosko Milekic Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mb_alloc cache balancer / garbage collector Message-ID: <20030217064130.GA62020@cirb503493.alcatel.com.au> References: <20030216213552.A63109@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030216213552.A63109@unixdaemons.com> User-Agent: Mutt/1.4i 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 On Sun, Feb 16, 2003 at 09:35:52PM -0500, Bosko Milekic wrote: > I've finally gotten around to implementing the cache balancer/garbage > collector for the mbuf allocator. Actually, it's been sitting in a > local tree for a while but I finally got one of my -CURRENT machines > back up and was able to debug it. Excellent. > For one, you can have network device drivers call the mbuf code > without Giant because they'll know for a fact that Giant will never be > needed down the line. Since the cache balancer will replenish caches > when they're under a low watermark, assuming a well-tuned system, no > noticable impact will be felt on mbuf allocations and deallocations. My only concern is that replishment is reliant on scheduling a process (kernel thread) whilst allocation occurs both at interrupt level and during normal process operation. Is it possible for a heavily loaded system (and a heavy traffic spike) to totally empty the mbuf cache in the interval between the low watermark being reached and the allocator actually running? If so, what happens? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message