From owner-freebsd-arch Sun Feb 16 23:25:57 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 7ECBC37B401 for ; Sun, 16 Feb 2003 23:25:56 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA0D643FBD for ; Sun, 16 Feb 2003 23:25:53 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id h1H7PqnN029060 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 16 Feb 2003 23:25:53 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <316301c2d655$cdfb2df0$52557f42@errno.com> From: "Sam Leffler" To: "Peter Jeremy" , "Bosko Milekic" Cc: References: <20030216213552.A63109@unixdaemons.com> <20030217064130.GA62020@cirb503493.alcatel.com.au> Subject: Re: mb_alloc cache balancer / garbage collector Date: Sun, 16 Feb 2003 23:25:52 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 > > 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? > With kernel preemption this should be less of an issue. Presumably the balancer thread runs with high enough priority to take preemptive control quickly. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message