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 - [EMAIL PROTECTED]
Systems Engineer - Internetworking Engineer - CCIE 3440
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
