Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Feb 2003 19:29:52 -0500
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: mb_alloc cache balancer / garbage collector
Message-ID:  <20030217192952.A67225@unixdaemons.com>
In-Reply-To: <20030217192418.A67144@unixdaemons.com>; from bmilekic@unixdaemons.com on Mon, Feb 17, 2003 at 07:24:18PM -0500
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>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030217192952.A67225>