Date: Sat, 06 Jun 1998 05:28:56 -0700 From: David Greenman <dg@root.com> To: John Hay <jhay@mikom.csir.co.za> Cc: cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_kern.c Message-ID: <199806061228.FAA14605@implode.root.com>
next in thread | raw e-mail | index | archive | help
> 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. There is one thing I forgot to mention in the above which is necessary before being able to understand the entire problem. The nature of the networking code, specifically the need to allocate memory in an interrupt context, adds additional constraints on how the allocator must work. More specifically, the virtual address space for the allocations must be set aside at system startup time, and for other reasons, can't be extended later. I'll offer this analogy: Imagine the kernel's memory space us a picture that will be made into a puzzle. Once the pieces have been cut, they become autonomous. All one can do is further divide them into smaller pieces. Such is the case with the various kernel maps. One might ask, 'why do we have maps in the first place - why not just make all of the kernel VA space one giant play area?'. The reason we have maps is to group similar allocations into distinct areas, usually to reduce virtual address space fragmentation, but in some instances to also provide controlled access to the area. Such is the case with the mb_map - it's necessary to protect all manipulations of it with spl protection so that the virtual allocations can be done in a device driver interrupt context as well as from other parts of the networking code. -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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806061228.FAA14605>