From owner-cvs-all Sat Jun 6 11:46:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05603 for cvs-all-outgoing; Sat, 6 Jun 1998 11:46:18 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA05581 for ; Sat, 6 Jun 1998 11:46:10 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.8/8.8.5) with SMTP id TAA05927; Sat, 6 Jun 1998 19:47:13 +0100 (BST) Date: Sat, 6 Jun 1998 19:47:13 +0100 (BST) From: Doug Rabson To: David Greenman cc: John Hay , cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_kern.c In-Reply-To: <199806060947.CAA14054@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Sat, 6 Jun 1998, David Greenman wrote: > >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. Incidentally, FreeBSD/alpha will have approximately 2x10^12 virtual memory space available for the kernel and about 4x10^12 available for each user process :-). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message