Date: Fri, 13 Jul 2001 14:03:26 -0400 From: Leo Bicknell <bicknell@ufp.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Matt Dillon <dillon@earth.backplane.com>, Leo Bicknell <bicknell@ufp.org>, hackers@FreeBSD.ORG Subject: Re: Network performance tuning. Message-ID: <20010713140326.A23982@ussenterprise.ufp.org> In-Reply-To: <3B4F36AE.857511FF@mindspring.com>; from tlambert2@mindspring.com on Fri, Jul 13, 2001 at 10:58:06AM -0700 References: <15.16ffaf54.287f3d4d@aol.com> <20010712135629.A49042@ussenterprise.ufp.org> <200107130128.f6D1SFE59148@earth.backplane.com> <3B4F36AE.857511FF@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 13, 2001 at 10:58:06AM -0700, Terry Lambert wrote: > > We can do all of this without ripping out the pre-allocation of > > buffer space. I.E. forget trying to do something fancy like > > swapping out buffers or virtualizing buffers or advertising more > > then we actually have etc etc etc. Think of it more in terms of > > the system internally sysctl'ing down the send and receive buffer > > space defaults in a dynamic fashion and doing other reclamation to > > speed it along. > > The problem is that the tcpcb's, inpcb's, etc., are all > pre-reserved out of the KVA space map, so that they can > be allocated safely at interrupt, or because "that's how > the zone allocator works". I think the only critical resource here is MBUF's, which today are preallocated at boot time. There are memory fragmentation concerns with allocating/deallocating them on the fly. I am not going to even attempt to get into the world of kernel memory allocators, that's way out of my league. That said, the interesting cases (in increasing order of difficulty): 1) Allowing an admin to change the number of MBUF's on the fly (with sysctl). Presumably these would be infrequent events. 2) Allowing MBUF's to be allocated/deallocated in fixed size blocks easy for the allocator to deal with. (Eg, you always have 128k to 4 M of MBUF's allocated in 128k chunks.) 3) Allowing MBUF's to be fully dynamically allocated. I'm not sure I see any value to #3. I see huge value to #1 (when you run low, you can say double the number on an active server). If we get the warning I want (from another message) #1 becomes even more useful. #2 would take some study. The root question is does allocating them in blocks eliminate the memory fragmentation concern for the kernel allocator? If the answer is yes, it's probably something to look into, if the answer is no, probably not. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010713140326.A23982>