Date: Mon, 17 Feb 2003 17:01:10 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mb_alloc cache balancer / garbage collector Message-ID: <200302180101.h1I11AWr001132@apollo.backplane.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> <20030217192952.A67225@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302180101.h1I11AWr001132>