Date: Sun, 16 Feb 2003 23:25:52 -0800 From: "Sam Leffler" <sam@errno.com> To: "Peter Jeremy" <peterjeremy@optushome.com.au>, "Bosko Milekic" <bmilekic@unixdaemons.com> Cc: <freebsd-arch@FreeBSD.ORG> Subject: Re: mb_alloc cache balancer / garbage collector Message-ID: <316301c2d655$cdfb2df0$52557f42@errno.com> References: <20030216213552.A63109@unixdaemons.com> <20030217064130.GA62020@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?316301c2d655$cdfb2df0$52557f42>