From owner-freebsd-arch Mon Feb 17 17: 1:15 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 8EE7137B401 for ; Mon, 17 Feb 2003 17:01:13 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E935543F85 for ; Mon, 17 Feb 2003 17:01:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h1I11ASJ001133; Mon, 17 Feb 2003 17:01:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h1I11AWr001132; Mon, 17 Feb 2003 17:01:10 -0800 (PST) Date: Mon, 17 Feb 2003 17:01:10 -0800 (PST) From: Matthew Dillon Message-Id: <200302180101.h1I11AWr001132@apollo.backplane.com> To: Bosko Milekic Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mb_alloc cache balancer / garbage collector 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> <20030217192952.A67225@unixdaemons.com> 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 : 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 I guess I still don't understand the point of the daemon. The per-cpu caches are limited (in your patch) to 512 mbufs / 128 clusters. This represents very little memory even if you multiply by ncpus. We shouldn't have to 'balance' anything. Who cares if there are 511 mbufs sitting on cpu 0's cache that aren't being used? These numbers are going to be tuned for the machine (for example, based on the amount of main memory), and are far smaller then the total possible. The only case that matters is if a per-cpu cache gets blown up by an inordinate number of frees being done to it. That is, when the mbuf or cluster count exceeds mbuf_limit or clust_limit. Why is the daemon more preferable for handling this case verses freeing a bunch (like 8 or 16) mbufs/clusters on the fly at the time of the free when the per-cpu cache exceeds the limit? I don't see any advantage to having the daemon at all, and I see several disadvantages. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message