From owner-freebsd-arch Mon Feb 17 16:30:16 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 DA4F737B401 for ; Mon, 17 Feb 2003 16:30:14 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FEDC43F93 for ; Mon, 17 Feb 2003 16:30:14 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h1I0Tqt67252; Mon, 17 Feb 2003 19:29:52 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Mon, 17 Feb 2003 19:29:52 -0500 From: Bosko Milekic To: Matthew Dillon Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mb_alloc cache balancer / garbage collector Message-ID: <20030217192952.A67225@unixdaemons.com> References: <20030216213552.A63109@unixdaemons.com> <15952.62746.260872.18687@grasshopper.cs.duke.edu> <20030217095842.D64558@unixdaemons.com> <200302171742.h1HHgSOq097182@apollo.backplane.com> <20030217154127.A66206@unixdaemons.com> <200302180000.h1I00bvl000432@apollo.backplane.com> <20030217192418.A67144@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030217192418.A67144@unixdaemons.com>; from bmilekic@unixdaemons.com on Mon, Feb 17, 2003 at 07:24:18PM -0500 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 Mon, Feb 17, 2003 at 07:24:18PM -0500, Bosko Milekic wrote: > This will not happen in the common case. The one exception is if your > caches are not balanced or are too low. Assuming that the watermarks > are tuned properly you should always have about the average of the > watermarks in your caches; if you don't, all the daemon will do is > replenish them to that value. Once that's done, it won't do anymore > replenishing unless you go low again. Further, if you spike and then > return back to normal, the free code will end up moving buckets of > objects back to the general cache and the daemon will only free back > to the VM from the global cache and, again, it won't free everything, > but just enough to bring back the general cache number of objects to > the average of the watermarks. So, you can still allocate from the VM > in your allocation paths if you need to, but instead of wasting time > allocating a bunch of buckets, setting up your free object lists, > etc.etc., you'll only allocate one bucket and let the daemon do the > rest. One more thing I forgot to add that may help clear this up: the less the daemon runs, the better. Right now I can see how many times it ran by looking at a sysctl-exported counter, mbuf_daemon_ran. I can see that it only runs once to populate the caches and then only runs if I forcibly spike and return back to 'normal' steady activity and if I change the watermarks to force it to run. We should probably eventually have it track and detect an acceleration of running occurances and then, according to that, change the watermarks if it starts to increase (i.e., if it starts to run too much). As I said, in the normal case, it shouldn't run often. This thing doesn't wake up every N ticks. -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org "If we open a quarrel between the past and the present, we shall find that we have lost the future." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message