Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:6581 comp.os.386bsd.bugs:1734 comp.os.386bsd.misc:1399 Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!convex!cs.utexas.edu!swrinde!emory!ogicse!psgrain!agora!davidg From: davidg@agora.rain.com (David Greenman) Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs,comp.os.386bsd.misc Subject: Re: [FreeBSD-1.0R] Epsilon -> Release patches - problems Message-ID: <CG57or.LHL@agora.rain.com> Date: 7 Nov 93 22:26:49 GMT Article-I.D.: agora.CG57or.LHL Organization: Open Communications Forum Lines: 28 >The above paragraph is assuming that you allocate more buffer headers >than pages; if not, then it hardly matters, because you could just >assign a page to each buffer header statically. Yeah, well, we don't! ...and this makes all of the rest of your analysis false. The downside of having fewer headers (in the case of FreeBSD, there are only half as many headers as there are 8k buffers, and an equal number in the case of 4k buffers) is it reduces the size of the cache when working with small buffers (4k, 1k, 512). But this memory isn't 'wasted', it's just returned to the main memory pool. Now, this is actually quite important because, unlike the FS cache in NetBSD, buffer space isn't wasted. If your cached block is 1k, then it consumes just 1k of memory. >Multiplied by a monotonically increasing factor for the fragmentation >mentioned above. Fragmentation isn't a problem. The only sized chunks which aren't currently released are 1k and 512 ones...and these do waste a small amount of memory - as much as 1-2%. But even this will be fixed in 1.1. Very, very few things in the system (like almost nothing) malloc 1k or 512 bytes chunks; basically only the filesystem code does this. This is the primary reason that fragmentation isn't a problem. (For those who don't know, the BSD malloc code uses a bucket scheme to allocate space, which by it's very nature, keeps fragmentation minimized). -DG