Date: Mon, 17 Feb 2003 09:44:38 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mb_alloc cache balancer / garbage collector Message-ID: <20030217094438.A64558@unixdaemons.com> In-Reply-To: <20030217064130.GA62020@cirb503493.alcatel.com.au>; from peterjeremy@optushome.com.au on Mon, Feb 17, 2003 at 05:41:30PM %2B1100 References: <20030216213552.A63109@unixdaemons.com> <20030217064130.GA62020@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 17, 2003 at 05:41:30PM +1100, Peter Jeremy wrote: > > 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? This is a legit concern. We try to avoid having this happen by: 1) Running the daemon at sufficient priority (PVM) 2) Properly tuning the watermarks However, it should be noted that even if this does happen right now, it's OK because I haven't yet instrumented the M_DONTWAIT case to NOT touch the VM code. That is, in the version of the patch I posted, M_DONTWAIT is still allowed to allocate a page from VM if it can't find anything in the cache(s). There is no forseeable reason that it should not be allowed to keep doing that in the long term. The reason we wanted to remove VM allocations in the M_DONTWAIT case is so that we could safely lock-down parts of network device drivers and remove the requirement for them to keep Giant across mbuf allocations. However, I think that perhaps kmem_malloc() no longer requires Giant (I know kmem_free() does)... so perhaps we could just leave things as they are, in which case you don't have to worry about the spikes except that, of course, making the VM calls makes the allocation more expensive so you still want to make sure you properly tune the watermarks[*]. [*] Speaking of which, I'm still looking for clever auto-tuning algorithms. > Peter -- 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?20030217094438.A64558>