Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!convex!cs.utexas.edu!math.ohio-state.edu!sol.ctr.columbia.edu!news.kei.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mycroft From: mycroft@duality.gnu.ai.mit.edu (Charles Hannum) Newsgroups: comp.os.386bsd.bugs Subject: Re: [FreeBSD 1.0e] Kernel's bss has grown up Date: 07 Nov 1993 18:16:14 GMT Organization: MIT Artificial Intelligence Lab Lines: 61 Message-ID: <MYCROFT.93Nov7131614@duality.gnu.ai.mit.edu> References: <2bd92f$4t@keltia.frmug.fr.net> <MYCROFT.93Nov6093036@duality.gnu.ai.mit.edu> <1993Nov7.101416.26351@emba.uvm.edu> <JTSILLA.93Nov7094722@merrimack.ccs.northeastern.edu> NNTP-Posting-Host: duality.ai.mit.edu In-reply-to: jtsilla@merrimack.ccs.northeastern.edu's message of Sun, 7 Nov 1993 14:47:22 GMT In article <JTSILLA.93Nov7094722@merrimack.ccs.northeastern.edu> jtsilla@merrimack.ccs.northeastern.edu (James Tsillas) writes: Speaking of buffer allocation.. why is there a limit in the number of allocatable buffers in NetBSD 0.9? I have a machine with lots of memory and would like to allocate 2 MB or more to buffer via a -DBUFPAGES=xxxx in my param flags. This seems to work up to a point but is limited by the following line in arch/i386/i386/machdep.c: bufpages = min(NKMEMCLUSTERS*2/5, bufpages); /* XXX ? - cgd */ This is a bit of a kluge left over from 386BSD that was probably originally meant to avoid exceeding the kernel's virtual memory size on machines with lots of memory. You can do a quick calculation of when this limit *really* becomes relevant. In NetBSD-magnum (precursor to 1.0), the kernel has 28MB of virtual address space available, minus 6MB for the malloc area, and we'll say 2MB (high estimate) for other gunk, including the kernel text and data. We initially allocate one page for each buffer, and MAXBSIZE is two pages. The amount of memory allocated is 20% of physical memory. So 20MB of address space with allow 10MB of buffer space, and if you have a machine with >50MB you need a clamp on that value or you get a panic during startup. (10MB of buffer space is probably ridiculous anyway. A better algorithm for determining the size would be useful.) Now if we increase MAXBSIZE to 16k, as at least a few people have asked, the ratio becomes 4:1, so the maximum buffer space is 5MB and people with >25MB are going to have troubles. As MAXBSIZE increases more, it gets worse. About the only thing we can do at that point is move the kernel downward to enlarge its address space even more. This will likely generate numerous minor incompatibilities, in the boot blocks, in old kvm binaries, etc, but is probably the correct thing to do. Also note that doubling or quadrupling MAXBSIZE necessarily doubles or quadruples the size of the page table required for the buffer area (assuming the same amount of physical memory is allocated). The page table isn't very large (N/1k), but it's worth noting that you lose more memory. This is all different in 386BSD and FreeBSD, where kmem_alloc() is used to allocate buffer space. That implementation also has no way of reusing buffers between, e.g., file systems with different block sizes. Incidently, NKMEMCLUSTERS seems to be a fixed value regardless of how much memory you running. Except for the previous kluge, NKMEMCLUSTERS is only used to decide how much of the kernel's virtual address space should be carved out for the malloc pool. If your malloc pool needs to be larger than that, I would suggest you have other problems. Now, while on the subject.. does NetBSD 0.9 support >16 MB memories using DMA controllers such as Adaptec. 0.9 does not.