Date: Mon, 25 Nov 2002 20:13:46 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Julian Elischer <julian@elischer.org>, Robert Watson <rwatson@freebsd.org>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <15842.51914.871010.137070@grasshopper.cs.duke.edu> In-Reply-To: <20021125160122.A75673@unixdaemons.com> References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <Pine.BSF.4.21.0211232306410.28833-100000@InterJet.elischer.org> <15841.17237.826666.653505@grasshopper.cs.duke.edu> <20021125130005.A75177@unixdaemons.com> <15842.27547.385354.151541@grasshopper.cs.duke.edu> <20021125160122.A75673@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic writes: > > back. We'll also need a kproc that can wake up every now and then to > > expand the pool if allocations at interrupt time failed. Or do you > > already have a mechanism for that? > > The intended mechanism is the kproc and when the allocator was first > designed and written, I had taken that into account although I have <...> > (I hope that came out OK). As you can see, the concept is very simple > and with the current infrastructure should be fairly easy to > implement. If you're wondering, I was going to do is as a 5.1 feature > at some point because I've been so swamped with other things right now > and so I do not foresee being able to do this in time for 5.0. This looks ideal. I'm looking forward to it. > It is not out of date. The code means: > > "If you've given me a counter then I'll use it otherwise I'll try to > allocate one with malloc()." Ah, duh. Thanks. I'd better start providing one in my driver then.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15842.51914.871010.137070>