From owner-cvs-all Sat Jun 6 02:48:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA14966 for cvs-all-outgoing; Sat, 6 Jun 1998 02:48:43 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA14950 for ; Sat, 6 Jun 1998 02:48:40 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id CAA14054; Sat, 6 Jun 1998 02:47:20 -0700 (PDT) Message-Id: <199806060947.CAA14054@implode.root.com> To: John Hay cc: cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_kern.c In-reply-to: Your message of "Sat, 06 Jun 1998 08:05:18 +0200." <199806060605.IAA01513@zibbi.mikom.csir.co.za> From: David Greenman Reply-To: dg@root.com Date: Sat, 06 Jun 1998 02:47:20 -0700 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk >Is it really usefull to keep a limit for mbufs and mbuf clusters? Can't we >just do away with the limit and let it allocate more when it needs? At the It's not that we "keep a limit". The limit is imposed by physical space constraints in the kernel, specifically the size of the "mb_map" VM map. The total virtual address space available to the kernel is a limited resource and it's critical and required that one must do a juggling act to fit it all in. One cannot just arbitrarily create a huge map so that near boundless amounts of networking buffers can be allocated; this would lose on systems that don't need large numbers of network buffers but do need the space for something else. As a way of reducing the problem, one could increase the total kernel VA space (and thus give more room to the individual maps that are allocated from it), but due to bizzare reasons that of no fault of ours, this would break binary compatibility with BSDI's BSD/OS. Still, the default maximum that is configured is probably way too lean for many systems and we should probably increase this by 2-4 times what it is now. Since a one-size-fits-all value isn't feasible (and the requirements for individual systems can vary greatly), it's difficult to figure a proper default. FreeBSD already has several times more space for mbufs/mbuf clusters than did the original 4.4BSD, but we seem to still be behind the usage curve on modern, medium-large systems. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message